noise generators (forked from: Krita user community?)

[Matthew Woehlke]

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.

-- 
Matthew
"Doggy!" -- Robots from Freefall (http://freefall.purrsia.com)