Impasto discussion

[Boudewijn Rempt]

On Wednesday 07 July 2010, JL VT wrote:
> Let's see. So there's this rough idea of giving impasto support to
> Krita, let's flesh it out, shall we?.
> 
> I will use the term "layer" liberally here, I don't know about the
> specific names that things receive in Krita, so I'll use my own
> definition: layer is what the user can see in the interface screen
> described as a layer. And if a layer is described as a sublayer and
> displayed as one to the user, then it is a sublayer.
> 
> So far the way that makes the most sense to me, is to store impasto
> information as an optional sublayer attached to the normal layers that
> the user is accustomed to use.

We tried this before with the painterly framework -- add a second paint device 
to a layer with the painterly colorspace, storing wetness, height, viscosity 
etc. The disadvantage was, as Dmitry notes, speed. Though at that time we had 
a paint device with an iterator for every painterly feature.

> As the attached diagram explains, when the user stacks many layers,
> what's visible to him is the OVERLAP of the layer's colors, while,
> intuitively, a stack of impasto layers should look like the SUM of all
> the thickness in each layer.

That's worrying me a bit, because I think that very soon when painting all 
pixels will have max height. I guess that's why Corel Painter only has one 
impasto layer.

> I don't know how the final proyection --in the diagram, the layers
> displayed after the "=" sign-- is calculated or created for normal
> (color) layers, but for the impasto sublayers, I imagine it to be
> calculated as follows:
> 
> 1-- Each impasto sublayer is a simple 1-channel bitmap storing
> "thickness" information (optionally, there could be negative thickness
> in a layer, that doesn't happen in real life but digitally there's no
> such limitation).

Well, actually, negative thickness is sometimes used in modern painting :-). 
But it shouldn't concern us, I guess. We're not in the business of artfully 
slashed canvases.

> 2-- The sum of all this thickness is computed for the "=" layer (let's
> call it the "Result Layer")
> 3-- Information about the direction of a luminant is used to create a
> "bumpmap" using the thickness information stored in the Result Layer
> as a base.
> 4.- This proyection of the Impasto Result Layer is mixed with the
> normal image the user would see if there was no impasto, to obtain an
> "impasted" image.

If you go for aggregated impasto layers, then you need to setup a separate 
compositor for those, since the total height field needs to be applied to the 
resulting color projection at display time using bumpmapping.

> The reason to let every layer have its own (optional) impasto sublayer
> instead of using a single layer storing all impasto information, is
> that doing so would cause layers to not be completely independent of
> each other. Giving each layer its own impasto information would
> preserve layer independence.

I think Dmitry's concerns about having to iterate over two devices if we 
separate impasto paint device and paint paint device. However, I'm a bit wary 
of putting the impasto information in the colorspace. I would be plenty happy 
with one impasto layer that is not visible in the layerstack, like Corel 
Painter has. I'm also thinking that stacking impasto layers would soon lead to 
maxing out the height field (since it's addition, not compositing).

> I also think there should be an universal option for all paintops to
> do an impasto effect without a need to be explicitly implemented,
> similar to the brand new "eraser" mode.

Yes -- I think we can create an impasto option similar to the other paintop 
options we have, and we can then on a per-paintop basis decide which paintops 
need that option.

> Now, if you don't have any concern (and even if you do), what are the
> classes I should study to start implementing this design?. Should I
> create a new class?, if so, where should I store it?, what other
> classes should it inherit?. Also a quick pointer on how the eraser
> mode was created is appreciated.

The eraser mode is a composite op -- which is why it cannot erase to 
background color, in fact. That wouldn't be all that useful, I think.

Personally, I would say -- first try having one impasto device per image. Fill 
it with random nonsense. The reason for that is that I think the biggest 
problem is not the data model but the bumpmapping. That one impasto layer can 
either be modified by the paintops or be the result of aggregated impasto 
layers -- that is for later. But you will end up with one height field that 
needs to be used when bumpmapping.

You will have to write this twice: once for the qpainter canvas, once for the 
opengl canvas. Also, keep in mind the light direction when writing the 
bumpmapping stuff.

-- 
Boudewijn Rempt | http://www.valdyas.org