POV-Ray : Newsgroups : povray.binaries.images : assumed_gamma, overlapping textures and transmit. : Re: assumed_gamma, overlapping textures and transmit. Server Time
17 May 2024 17:44:31 EDT (-0400)
  Re: assumed_gamma, overlapping textures and transmit.  
From: clipka
Date: 21 Oct 2016 13:54:24
Message: <580a5650$1@news.povray.org>
Am 21.10.2016 um 15:39 schrieb William F Pokorny:
> On 10/20/2016 12:27 PM, clipka wrote:
>> Am 20.10.2016 um 16:28 schrieb William F Pokorny:
>>
>>> That said, I've spent a fair bit of time working through Norbert's
>>> material collection - mapping them to my own ag 1.0 versions and
>>> variants. I've been doing it as a way to learn from other's texturing
>>> work as much as anything. In my own work, I've hit upon occasions where
>>> I want a less linear and tighter blend between textures. The 2.2 space
>>> offers some of this - I suspect by side effect as much as intent.
>>
>> Maybe we can introduce a new "blend_gamma" parameter to textures, that
>> governs how the texture blends with the layer beneath it?
>>
> The idea strikes me as a good one.
> 
> Suppose the devil is in the details of implementation and actual use.
> Are you thinking initially of:
> 
> effective_transmit=pow(T,new_blend_gamma_parm) for each texture with a
> blend_gamma parameter?

Pretty much precisely that.

Though, thinking about it, for texture stacks that have semi-transparent
portions this raises the question whether the blending of the lowest
texture in the stack and the background should also be affected.

If that is the case, then all we'd really need to do to achieve that
effect would be to use a pigment that already has the desired effective
transmit value.

For pigments with constant transmit value that would mean simply
adapting the transmit component.

For pigments with non-constant transmit, presumably using a colour_map
or pigment_map, we could just extend the existing blend_mode /
blend_gamma mechanism, for example by introducing additional modes that
also cover the transmit and filter components of the pigment.

> Something this direct would address much of what I believe I'd like.
> 
> If we are going to add such a new control, perhaps the mechanism should
> be set up more flexibly than a parameter to a built in function - could
> be as much as complete control of the blend by function I guess.

If POV-Ray had a multi-channel function feature (which is something on
my todo list but still far from implemented), my suggestion would be to
simply provide some blend_function feature as an alternative for the
blend_mode / blend_gamma, that would take a function with eleven
parameters (the 2x5 channels of the pigment colours to be blended, and
the weight of the first colour) and return five result values (the 5
channels of the resulting pigment colour).

But until then, I am reluctant to implement any function-based solution
to the problem, as that would pose the risk of getting in the way of the
solution I would really want to implement.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.