noise generators (forked from: Krita user community?)

[Matthew Woehlke]

Boudewijn Rempt wrote:
> On Monday 25 February 2008, Matthew Woehlke wrote:
> 
>> 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?
> 
> Not yet, but it's no more than an evening's work to add a node type that can 
> take a generator, some input parameters and an explicit "regenerate" action, 
> as long as we generate just pixels in some sane color model. 

Ok. I do think this would be good for image-making "filters" such as the 
aforementioned set (perlin would be an obvious candidate for a test 
case); then the filter doesn't need to "re-run" any time the content 
beneath changes, since there won't be any effect anyway (except of 
course layer blending, which is decoupled).

>> 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.
> 
> That would be a little harder, but not much. We'd need to:
> 
> * add a color model that contains the 2 channels
> * add a plugin type that exposes a generate data function and a colormapping 
> function.

Where did colormapping come into the plugin? The idea was that the 
channel-generation is totally decoupled from the color mapping. So, my 
plasma generator (as an example) spits out, say, an FP64 per pixel, with 
no knowledge or concern for how that gets translated into color data.

> * add a node type that contains that plugin, a source paint device in the 2 
> channel color model and a projection in a regular color model

I don't know enough krita guts, but that sounds about right.

I'm envisioning one "layer" (node?) looking like this:

<generator> (plugin)
<filter> (maybe plugin but probably core; optional)
<colormap> (core)

Note that 'colormap' is basically the gradient map we talked about 
earlier, of course operating on the higher-bit-depth information from 
the previous stage. This would only be applied to the first channel.

The filter (one per channel, so one or two) would be somewhat like the 
'curves' adjustment tool.

There may even be some way to combine this with, or at least make it 
resemble (i.e. similar UI), HDRI tone mapping.

> * add a layer properties dialog that allows setting the data for both 
> functions in the plugin and has a regenerate button

Is there a technical problem making regenerate happen when the 
generator's parameters change? I'd rather not need a button; it should 
be automagic :-).

> Come to think of it, it would be nice if we could use such generators as input 
> for masks, too.

Hmm... yes, that is harder... or is it? I'd mentioned the second channel 
being alpha, I don't suppose we have a DestinationOver composition mode? 
I.e. some way to have Layer B a child of Layer A, where the blend of the 
two results in the alpha being either A*B or just B? It's not quite as 
elegant, but achieves the same effect with less complicated UI.

Btw, is this getting on a wiki anywhere, or is there a good place I 
should dump it?

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