Question about generator layers... (on the topic of fractal flames)

[Matthew Woehlke]

Boudewijn Rempt wrote:
> On Monday 05 May 2008, Matthew Woehlke wrote:
>> I've been looking more at Apophysis and realized that it's really just
>> an editor for IFS fractal flames, which have a number of implementations
>> and are more-or-less well defined. (I also discovered a *different* type
>> of fractal flame, or at least something that looks similar; namely the
>> de Jong equations ala http://fyre.navi.cx/, which I think I'd like to
>> try to implement first, as the math and configuration are trivial
>> compared to IFS, but the process of mapping the raw fractal data to
>> pixels seems to be similar.)
>>
>> The point is, fractal flames are rendered entities that can take a
>> *long* time to generate at high quality, and it would be I think optimal
>> if they could be generated in the background, so that one can continue
>> working with a low-quality version in the layer as it slowly refines
>> itself. (To generate "final" versions, one would simply leave Krita
>> running for a long time, to let the generator do its thing.) Obviously
>> this would need to be done at very low priority, or even be tied to a
>> 'render' button and suspended when the user starts doing things.
> 
> It's doable, but a serious complication (like, every time a layer is updated, 
> you'd need to update the whole rendering stack) but I'd prefer to postpone 
> that to after the release. After all, it's just an optimization.

I'm confused, what part exactly were you replying to? I don't see why a 
background-updating layer would be substantially different from painting 
on the same layer.

>> Incidentally, Fyre has the right idea; store the raw accumulation data
>> and post-process it. If Krita can do this, it will be a HUGE improvement
>> over GIMP, because - just like in Fyre - you'll be able to change the
>> exposure, gamma, and coloring in real time, without re-rendering (not
>> something to laugh at when the render can take hours or days to reach a
>> high quality level!).
> 
> Sure, that's doable in a generator plugin, but only in the sense that you'd 
> have to save both types of data. Raw data and finally rendered pixels. You'd 
> store the raw data in a parameter in the generator configuration, probably 
> using a paint device with a KisGenericColorSpace (so you get memory 
> management for free).

Ok. Having to store actual pixels feels a little annoying, but that's 
probably just me; intellectually, it's a reasonable optimization. The 
generator wouldn't use that information, but I think that's always the 
case with pretty much any generator.

>> Summary:
>> - Can Krita save generator layers along with an arbitrary data blob
>> defined by the generator? The generator will be required to quickly
>> translate that blob into channel data on load.
> 
> In a sense, yes -- it might need a little work to make it smooth in practice, 
> and it will always be necessary to also save the rendered pixels.

Ok.

>> - Can Krita allow generator layers to run in the background (or at user
>> request) to refine their data?
> 
> Yes, but not as easily and it's something I'd rather postpone until we've got 
> generators that do something.

That's acceptable. At any rate I don't expect to have an IFS flame 
generator functional any time soon, and even if I did, we're not talking 
anything time-critical here.

I *do* have a functional de Jong proof-of-concept program ala the plasma 
proof-of-concept; the basic version only took about an hour to write, 
and I've since spent a few more hours making it multi-threaded (and much 
more object-oriented) with background updates and near-real-time 
interactivity. I probably need to get that one in svn somewhere, as it's 
a good example of a progressive, background-updating generator.

I'd expect I'll want to hook in plasma first, since de Jong really needs 
quite some time (longer than you want to wait on a filter/generator to 
see something, anyway; gimp's flame drove me nuts while playing with it 
this weekend and de Jong seems to be if anything worse) to produce an 
acceptably smooth accumulation buffer; background rendering is almost 
mandatory I think.

-- 
Matthew
The signature file
Contains some witty humor
But most is just trite