A GSoC proposal to work on a canvas with realistic color mixing

Matthew Woehlke mw_triad at users.sourceforge.net
Tue Mar 30 17:55:22 CEST 2010


Boudewijn Rempt wrote:
> On Tuesday 30 March 2010, Matthew Woehlke wrote:
>> Boudewijn Rempt wrote:
>>> The other issue, getting a nice and detailed texture, can be solved in
>>> two ways. Gimp really isn't the best application to compare with here
>>> since it doesn't implement either. The first method is to store texture
>>> information (roughness, height map, wetness, etc) on the canvas, the
>>> other is to make a brush engine that paints in a way that gives a
>>> textured feel, like Krita's sumi-e or soft brush (with some settings).
>>
>> FWIW, the advantage of the first method is it is more realistic (can mix
>> with fluid-flow simulation)
>
> Well, that's out of scope for now.

True, I'm just saying I'd like to hope to see it eventually. Also that 
Painter /does/ take the first approach, at least as far as height. I 
don't think painter, in general, messes with physical qualities of the 
paint, though. Their wet layer is maybe a partial exception, but I don't 
remember Painter doing anything like real pigment mixing, at least 
outside of the aforementioned wet layer.

>> and lets you do things like fiddle with
>> lighting simulation. This is what Painter does (for those that don't know).
>
> Only for the bumpmapped impasto layer, as far as I know. They don't do
> lighting effects for wet paint, I think.

True, but I think that's reasonable, you don't usually present artwork 
while the paint is still wet and then throw it out after it dries :-). 
(Being able to simulate different reflective qualities of paint would be 
a plus, but I think that is still not as bad as trying to do real-time 
dynamic lighting simulation. Lighting seems like a case where 
quick-n-dirty and fast is preferred for real-time, and it's okay for 
anything fancier to be slow, maybe even quite slow - think 'render' 
here. Though I suspect GPU's are going to increasingly make it practical 
to do even fancier things here.)

>> What would be a really neat add-on to that is to store the paint
>> per-pixel as an array so that you remember the paint that is "lower".
>> Then you can implement tools to scrape away paint and see what is
>> underneath ;-).
>
> That would mean we have a sort of per-pixel layers. I think artists are
> comfortable enough with layers to allow them to achieve this effect already,
> though it's an interesting idea. The performance implications worry me,
> though.

Agreed. I didn't say it was practical :-) (not with current hardware 
anyway).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"It's not easy for [Microsoft] to accept [competing fairly]"
   -- Dave Heiner (a Microsoft VP, paraphrased)



More information about the kimageshop mailing list