Could someone who knows the inner workings of POV-Ray (and MegaPOV) please
tell me why transmit values outside the range of 0 to 1 work as they do?

And why does it work differently in MegaPOV than in POV-Ray 3.1?

In povray.binaries.images I have posted some graphs that show how the
transmit value seem to work in POV-Ray 3.1, in MegaPOV 0.6, and how I would
like it to work.

The reason I would like the transmit value to work different is that if it
works my way (which is more simple), it can be used for many different
special-effects such as inverting pigments and contrast-enhancing pigments.

My suggested change will most probably not brake any old scenes because it's
not very common to use transmit values outside the range of 0 to 1. Values
between 0 and 1 will work the same way as it currently does.

I have brought up this subject before, but not got the response I hoped for.
This time I *really* hope for some feedback - especially from people who
know what they're talking about! ;)

If you don't want to use my suggested change, could you at least tell me
*why* it should work as it currently does?

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 9)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune wrote:
> 
> Could someone who knows the inner workings of POV-Ray (and MegaPOV) please
> tell me why transmit values outside the range of 0 to 1 work as they do?
> 
> And why does it work differently in MegaPOV than in POV-Ray 3.1?
> 
> In povray.binaries.images I have posted some graphs that show how the
> transmit value seem to work in POV-Ray 3.1, in MegaPOV 0.6, and how I would
> like it to work.
> 
> The reason I would like the transmit value to work different is that if it
> works my way (which is more simple), it can be used for many different
> special-effects such as inverting pigments and contrast-enhancing pigments.
> 
> My suggested change will most probably not brake any old scenes because it's
> not very common to use transmit values outside the range of 0 to 1. Values
> between 0 and 1 will work the same way as it currently does.
> 
> I have brought up this subject before, but not got the response I hoped for.
> This time I *really* hope for some feedback - especially from people who
> know what they're talking about! ;)
> 
> If you don't want to use my suggested change, could you at least tell me
> *why* it should work as it currently does?
> 
> Rune

So you're saying that the colour should be simply (1-t)*pigment +
t*background ?
Sounds good to me.  I've used strange transmit values to modify the
background colour but in that case I usually use rgbt of
<0,0,0,SomeOddValue> so the change would not affect me.
BTW I don't know why MP clamps negative values to zero.

PoD.

Post a reply to this message

"PoD" wrote:
> So you're saying that the colour should be simply
> (1-t)*pigment + t*background ?

Yep. Just like it is for values between 0 and 1.

> Sounds good to me.  I've used strange transmit values
> to modify the background colour but in that case I
> usually use rgbt of <0,0,0,SomeOddValue> so the change
> would not affect me.

Here's an inverting pigment:
pigment {color rgb 0.5 transmit -1}

It works in official POV-Ray, but not in MegaPOV.

Here's a contrast-enhancing pigment:
pigment {color rgb 0.5 transmit 2}

However, it doesn't work. It would only work if the transmit value was
changed to work the way I suggest...

> BTW I don't know why MP clamps negative values to zero.

Neither do I and I would *really* like someone to explain it to me...

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 9)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a04a179@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> > BTW I don't know why MP clamps negative values to zero.
> 
> Neither do I and I would *really* like someone to explain it to me...

Perhaps because it was intended to simulate transparency and was only 
designed to work in the range of 0-1?
As far as I can tell, MegaPOV does it the way it is supposed to work. I 
do think there needs to be a more powerful way of specifying 
transparency, and a separate way for specifying transparence in layered 
textures.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> > > BTW I don't know why MP clamps negative values to zero.
> >
> > Neither do I and I would *really* like someone to explain it to me...
>
> Perhaps because it was intended to simulate transparency and
> was only designed to work in the range of 0-1?
> As far as I can tell, MegaPOV does it the way it is supposed
> to work.

If it is supposed to be used in the range of 0 to 1 only, then using values
outside this range should generate an error or at least a warning.

However, there is no reason to confine the valid values to be from 0 to 1.
Being able to use values outside this range will be *very* useful - not for
realism, but for many other things.

Anyway, values outside the 0 to 1 range *can* be used; the question is why
it works in such a strange way. Is there an actual senseful reason behind,
or was it coded this way for no particular reason?

I would find it very annoying if I am prevented from effectively using a
powerful feature for "no particular reason". I'm not saying that there isn't
a good reason for the way it works, but it really bothers me not to know
what it is, or if there is one at all.

That's why I would *reeeaally* like to be told *why* *it* *works* *as* *it*
*does*!
(Both for official POV-Ray and for MegaPOV).

Oh well, I guess that if you want to have something changed, you gotta do it
yourself.
And if you can't - sigh...

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 9)
/ Also visit http://www.povrayusers.org

Post a reply to this message

I have to admit that Rune's suggestion (in p.b.i) looks rational and makes
sense. It certainly can be useful that way.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
>   I have to admit that Rune's suggestion (in p.b.i) looks rational and makes
> sense. It certainly can be useful that way.

Me too :-)

Does Rune already have the patch to do it that new way?

Post a reply to this message

"J. Grimbert" wrote:
> Warp wrote:
> >
> >   I have to admit that Rune's suggestion (in p.b.i) looks
> > rational and makes sense. It certainly can be useful that way.
>
> Me too :-)
>
> Does Rune already have the patch to do it that new way?

Nope, unfortunately not, it's more like a feature request.

Maybe if this thread grows big enough the right people will begin to notice
it! ;)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 9)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune wrote:
> 
> "J. Grimbert" wrote:
> > Does Rune already have the patch to do it that new way?
> 
> Nope, unfortunately not, it's more like a feature request.
> 
> Maybe if this thread grows big enough the right people will begin to notice
> it! ;)
> 

Well, I'm not the right people, but I have done the patch.
(see p.b.i for illustration).

As it is really easy for 3.1g (and short), I give it inline here

in lighting.c, find the line in comment and replace with the next:

      /* Att = Trans * (1.0 - min(1.0, LayCol[FILTER] + LayCol[TRANSM])); */
      Att = Trans * (1.0 - (LayCol[FILTER] + LayCol[TRANSM])); 



As I do not have the MegaPov sources, it is left as an exercise
for the MegaPov maintainers... 

P.S. : I stated the patch was easy, well, not that easy. The computation 
of the colour applies to layered textured, so I had to understand the code
first.

Post a reply to this message

In article <3a05e6c8@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Anyway, values outside the 0 to 1 range *can* be used; the question 
> is why it works in such a strange way. Is there an actual senseful 
> reason behind, or was it coded this way for no particular reason?
> That's why I would *reeeaally* like to be told *why* *it* *works* 
> *as* *it* *does*! (Both for official POV-Ray and for MegaPOV).

Because it was designed to work for values between 0 and 1, and 
apparently someone didn't take into account the use of values outside 
that range. Someone probably noticed that although it only works 
properly in the [0, 1] range, it allowed values outside that range, so 
they "fixed" it, not realizing values outside that range had any use.
Or maybe it messes up layered textures or something...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message