Hello!

I noticed something strange about the way POV-Ray handles transmit values.

I wrote about it in the thread "transmit > 1 ?", but I didn't get so many
replies to my questions, so I try again.

To show what I'm talking about I have made some graphs. You can see them in
povray.binaries.images .

They show the strange way POV-Ray handles transmit values above 1. I know
that a transmit value above one (or below zero) is an unrealistic thing, but
it can be used for useful special effects. POV-Ray handles transmit values
in a certain mathematically way. That is true for transmit values between 0
and 1 but also for negative values. The way POV-Ray handles such transmit
values is fully logical and predictable if you understand it. The problem is
that POV-Ray handles transmit values above 1 in another way, and that is
very annoying. I think POV-Ray simply ignores the color of the surface when
the transmit value of the surface is above 1. But I think it shouldn't
ignore it. If for example a transmit value of 1.3 is present, the color of
the surface should be multiplied with -0.3 because the surface color is
normally always multiplied with ( 1 - transmit_value ).

Anyway, my point is that POV-Ray should be changed so it handles transmit
values above one in the same way as it handles other transmit values. It may
not be intuitive, but the present method isn't intuitive either. The
advanced user will benefit from the change.

Greetings,

Rune

---
Updated April 25: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!

Post a reply to this message

Hello...?

Anybody care to reply...?

(and I even made nice graphs and everything...)

Greetings,

Rune

---
Updated April 25: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!

Post a reply to this message

I care, really I do  ;-)
I only glanced over the graph before.  So little time, etcetera etcetera.
Thing is I guess is that transmit is somehow intended to, well, transmit.
Something akin to emission in media let's say.  Whether that's right or wrong
is up to the POV gods I suppose.  You're right though, it's something which
doesn't seem to adhere to a pure transparency sort of thing as it appears to
be doing within the confines of only a 0 to 1 range.  It seems the rgb 0 (or
blacker) end of the spectrum is given a certain priority.  I don't know if I'm
wording any of this very well.
Did you also try graphing 'filter' in this same way?  Talk about something
that emits when >1 !
Anyhow, very good job of graphing.

Bob

"Rune" <run### [at] inamecom> wrote in message
news:3924881d@news.povray.org...
| Hello...?
|
| Anybody care to reply...?
|
| (and I even made nice graphs and everything...)

Post a reply to this message

"Bob Hughes" wrote:
> I care, really I do  ;-)

:-)

> Thing is I guess is that transmit is somehow
> intended to, well, transmit. Something akin
> to emission in media let's say.

What I complain about that the color of the surface is ignored. And for a
strange reason it is *only* ignored with transmit values above 1. It
shouldn't ever be ignored.

> Whether that's right or wrong is up to the
> POV gods I suppose. You're right though, it's
> something which doesn't seem to adhere to a
> pure transparency sort of thing as it appears
> to be doing within the confines of only a 0 to
> 1 range.

No, my point is that actually it works "correctly" with *all* values below
1. Even negative values. Transmit values above 1 should simply work just the
same way.

> It seems the rgb 0 (or blacker) end of the
> spectrum is given a certain priority.  I don't
> know if I'm wording any of this very well.

Normally the color you see when looking at a transmitting surface is
transmit_value * color_behind_surface + ( 1 - transmit_value ) *
surface_color

That is true for all transmit values below 1. But transmit values above one
is handled differently:
transmit_value * color_behind_surface

That is, the surface color is totally ignored.
At least I *think* it works that way. It seems so.

Currently there's some certain useful effects you can't achieve. If my
suggestion is followed, these effects would be possible to achieve, and in
most cases you would still be able to achieve the old (current) effects too.

I know that my suggestion is not intuitive, but the current method isn't
intuitive either. When using transmit values above 1 one should expect
intuitive results at all.

Furthermore, if the transmit code in POV-Ray works the way I think it works,
then following my suggestion would not require any new code. Only some
existing code should be removed. Something similar to a #if statement I
guess. Instead of using one formula for transmit values below one and
another for transmit values above one, the same formula should be used for
all transmit values. Simple and logical I think.

> Did you also try graphing 'filter' in this
> same way? Talk about something that emits
> when >1 !

I didn't try graph that. Maybe I should...

> Anyhow, very good job of graphing.

Thanks!

Now I just hope some POV programmers or patch makers will look at the
problem, or at least reply here...

Greetings,

Rune

---
Updated April 25: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!

Post a reply to this message

"Rune" <run### [at] inamecom> wrote in message
news:392533b1@news.povray.org...
|
| What I complain about that the color of the surface is ignored. And for a
| strange reason it is *only* ignored with transmit values above 1. It
| shouldn't ever be ignored.
|
| No, my point is that actually it works "correctly" with *all* values below
| 1. Even negative values. Transmit values above 1 should simply work just the
| same way.
|
| > It seems the rgb 0 (or blacker) end of the
| > spectrum is given a certain priority.

I was just getting at the idea that maybe darker (toward rgb 0) colors with
transmit applied might be "enhanced" to convey it's own pigment and not that
of the background.  Checking the graph once again it appears my imperfect mind
switched the graphs on me, in a way anyhow.  What I was actually intending to
be saying before was that the transmit is probably supposed to increase
intensity (saturation?) of any color greater than rgb 0 (leaving rgb 0 alone
still for >1 values of transmit).  Sorry, but I don't express myself clearly
even when I try.
So.... to make an assumption, I'd have to say the way transmit works must've
been planned that way.  Acting as a kind of pigment (including background)
booster.  And reason I mentioned filter too was because I think it probably
does likewise.
Btw, I'm also wondering why no one else has spoken up about any of this.

Bob

| then following my suggestion would not require any new code. Only some
| existing code should be removed. Something similar to a #if statement I
| guess. Instead of using one formula for transmit values below one and
| another for transmit values above one, the same formula should be used for
| all transmit values. Simple and logical I think.
|
| > Did you also try graphing 'filter' in this
| > same way? Talk about something that emits
| > when >1 !
|
| I didn't try graph that. Maybe I should...
|
| > Anyhow, very good job of graphing.
|
| Thanks!
|
| Now I just hope some POV programmers or patch makers will look at the
| problem, or at least reply here...
|
| Greetings,
|
| Rune
|
| ---
| Updated April 25: http://rsj.mobilixnet.dk
| Containing 3D images, stereograms, tutorials,
| The POV Desktop Theme, 350+ raytracing jokes,
| miscellaneous other things, and a lot of fun!
|
|

Post a reply to this message