noise generators (forked from: Krita user community?)
mw_triad at users.sourceforge.net
Mon Feb 25 19:26:53 CET 2008
Boudewijn Rempt wrote:
> On Monday 25 February 2008, Matthew Woehlke wrote:
>> Of course, another question might be if we care about partial updates?
> If you want your filter to be enabled for filter nodes (i.e, non-destructive
> updates) then yes, unless it's blindingly fast. Of course, this generates
> data, so making it into a dynamic node type of thing is less important.
Right, that's about what I thought. Since this does not take any data
input (as opposed to parameter input), there is never a need to
regenerate the data because a layer underneath changed, only if the
parameters change, and in that case everything is invalid, so...
>> If not, a (much) simpler way would be to parallelize only the guts of
>> each sub-pass and lockstep all threads between passes. This would allow
>> one thread per pixel (except many would have nothing to do the first
>> pass), since the data is write-on
> We are considering putting in convergence phases for filters that absolutely
> need all input information in a particular node to done, ready and available
> for the filter; those filters cannot be threaded and will cause a point of
> serialization in the projection update code. I.e, they will slow down things.
> The way krita works now has a big advantage: the image is tiled in fairly big
> tiles and every tile is given to a thread. A thread gets to work out its tile
> before releasing control and giving another thread a chance. That means that
> the projection data doesn't get bumped out of the cache all the time, as it
> would if you were to update the whole image whole layer by whole layer. And
> it makes it possible to display the tiles that are ready already, giving the
> user the impression of responsiveness. And it makes it possible to defer the
> procession of out-of-view tiles to idle periods, making krita do the least
> possible amount of work.
Right, I more-or-less understand that (from following the list). So it
wouldn't be fun to make everything halt for one filter.
On the other hand... it still doesn't need any inputs, it's only
dependent on itself, and it *can* be threaded as long as each pass can
be held for the previous one to complete. But, it sounds like that would
mess up the tile model pretty well.
But... it might be worth it. I can think of other filters that either
don't depend on the underlying data or else can be implemented
identically by generating regular channel data and using a generic
composition mode, and that would be awkward to break into tiles. Perlin
noise certainly has the former attributes (and indeed, any procedural
generator, I would think), the plasma generator has both, Apophysis* has
the former and probably the latter, as do lens flare (in RGB composition
mode at least) and GIMP's supernova. That's a decent chunk of filters
that could likely benefit, if only in code maintainability, from an
out-of-tile calculation model.
Basically, any generator filter (and *especially* something like
Apophysis that is extremely slow) lends itself to a render-once model
whereafter it is treated like a normal paint layer, but with the
advantage that you can go back, adjust the parameters, and re-render
(and of course change the composition mode at any time). Maybe there is
already a model for this?
Food for thought, anyway.
(* And, yes, I would *really* like to see an Apophysis plug-in in krita
I think I would still, eventually, like to see a "fractal" layer type,
that consists of one or two channels of scalar data (64-bit FP as at
least one option), plus a filter function (per channel?), plus a color
mapping. Perlin, plasma, and Apophysis, as well as any future procedural
generators, could all be used as front-ends for the channel data. The
first channel would be gradient-mapped, the second (if present) used as
an alpha channel.
"Doggy!" -- Robots from Freefall (http://freefall.purrsia.com)
More information about the kimageshop