Explaining the Scratch Off algorithm of the Hatching brush

LukasT.dev@gmail.com lukast.dev at gmail.com
Sat Jun 19 18:10:26 CEST 2010


On Saturday, June 19, 2010 17:44:54 JL VT wrote:
> My original aim with the brush was giving artists a tool to make
> boring(tm), very regular hatching directly with a tool instead of having
> to use time-consuming filters. With time I've been thinking of also
> allowing the user to do a more "organic" hatching too (
> http://bmia.bmt.tue.nl/Research/MVIAV/IVR/ivrsb/index.php?Page=Hatching ;
> check the middle skull), but that would take long, I'd surely have to
> sacrifice not finishing a halftone brush to work on that. I think it's
> worth the attempt though.

The pictures you sent are from Volume rendering, which means that the hatching 
is based on 3D information. That's why it looks so cool. I'm not sure how do 
you want to reach that effects? I think it would eat quite a lot of time, so my 
inner feeling is go for the halftone brush.

What about other devs? boud?
 
> Now, with respect to "boring, very regular" hatching, the current algorithm
> (described in the GUI as trigonometry-algebra) has the problem that lines
> thicken in incremental mode (opaque background off) and look jagged in wash
> (opaque background on). Part of the jagging comes from the fact that the
> tips in the borders of the lines look different than the inner parts, so
> cutting those borders would help; that would have the extra benefit of
> reducing thickening in incremental mode. But even so, the lines get
> inherently out of sync when drawn little-chunk by little-chunk instead of
> all at a time; I am sure that it is due to the rasterization step, because
> I did the algebra carefully, and floating-point calculations aren't THAT
> imprecise to cause such errors to arise (or are they?).

You might revisit the rasterization code. Maybe try to write some debug code 
and see how is our rasterization code behaving and fix the problem, if you are 
able. I spent some time on rasterization when I was working on GSoC 2008, 
there were problems with lines so I left the code as it was.
 

> I believe the "no jagging and less thickening" benefit is remarkable, it
> would make the hatching generated look almost as clean if it were made by a
> filter, but it would be generated in real time and directly on the canvas
> by the user, instead of requiring the user to mount an elaborate set of
> layers and apply filters on it to get his final result (besides, the
> GIMP's Newsprint filter isn't too versatile with the hatching, so it would
> take the user many iterations and therefore a great deal of time to
> achieve areas with different thickness or with crosshatching, using that
> filter).

> Endnote: with respect to Incremental and Wash: the dialogue the UI offers
> for choosing between incremental and wash mode has different effects than
> what I envisioned as the "opaque background" option, that's why I want both
> to coexist. When I link the BrushTip dialogue I'll make a proof of concept.

Would you document all those options you have in your paintop in the wiki?
E.g. I did preliminary docs for spray [1] long time ago (older then Internet),
it's not up-to-date, but you have inspiration.

[1] http://wiki.koffice.org/index.php?title=Paintops/Spray_brush


More information about the kimageshop mailing list