Viewing a glow through a completely transparent object changes its
brightness. This seems odd since the object is completely transparent and
should not affect anything that is behind it.
  Here is an example. A completely transparent cylinder is partially in
front of a glow (and a sphere) so you can clearly see the difference.
  Note that you can see part of the shape of the cylinder in the reflection
in the floor due to the dimmed glow.
  Filtering has the exact same effect.

  Oddly enough, this same effect happens even if the transparent object
is BEHIND the glow instead of being in front of it.
  You can test it by changing the 'Dist' identifier in the code, which sets
the position of the cylinder in the z-axis.
  Change it to '2' to see that the effect persists.
  Change it to '10' for another good example of the cylinder being behind the
glow.

  I think it has something to do with the length of the ray being calculated
(and perhaps it's a known problem).

#version unofficial MegaPov 0.6;

camera { location <-1,2,-14> look_at -y angle 35 }
light_source
{ <50,200,-100>,1
  spotlight point_at 0 radius 1 falloff 2
}
plane { y,-2 pigment { checker rgb 1, rgb z } finish { reflection 1 } }

sphere { 0, .75 pigment { rgb x } finish { specular .5 } }
glow
{ type 1 location 0 size .1 radius 2 fade_power 3
  color <1,1,0>
}

#declare Dist = -2;

cylinder { <1,-1,Dist>,<1,2,Dist>,1 pigment { rgbt 1 } }


-- 
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:
> 
>   Viewing a glow through a completely transparent object changes its
> brightness. This seems odd since the object is completely transparent and
> should not affect anything that is behind it.
[...]
> glow
> { type 1 location 0 size .1 radius 2 fade_power 3
>   color <1,1,0>
> }

according to Chris Huff there is a problem with glows using the 'size' modifier
interacting with other objects, but in your scene the problem still exists when
you avoid 'size'.  

After removing both 'size' and 'fade_power' i had no more any problems, so those
two things still seem to have bugs.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <39EC8299.274E9873@schunter.etc.tu-bs.de>, 
chr### [at] gmxde wrote:

> according to Chris Huff there is a problem with glows using the 
> 'size' modifier interacting with other objects, but in your scene the 
> problem still exists when you avoid 'size'.  

This is right...don't use "size".

> After removing both 'size' and 'fade_power' i had no more any 
> problems, so those two things still seem to have bugs.

In the case of fade_power, more of a cheat in the algorithm, more like 
the way turbulence doesn't make 3D variations in the glow. This was just 
something I added to adjust the falloff of the final values, which makes 
it dependant on distance. The transparent object breaks the ray in two 
parts, and the second one is shorter...which makes the result different.

So: don't use "size" yet, it is buggy, and don't use "fade_power" if you 
want a remotely realistic image. If you want realism and 
flexibility...use media. :-)
I will eventually have new falloff functions with adjustable falloff 
amounts which should make fade_power unnecessary.

-- 
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 <chr### [at] maccom> wrote:
: So: don't use "size" yet

  Does "size" have any effect on rendering speed? Its description sounds like
it would define a kind-of bounding sphere.

: and don't use "fade_power" if you 
: want a remotely realistic image.

  Well... To me "fade_power 2" looks more realistic than the default
(exactly for the same reason that a fading light source with fading power 2
is more realistic).
  So I hope you fix it soon :)

: If you want realism and flexibility...use media. :-)

  But media is slow and requires a lot more tweaking.

-- 
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

In article <39ed6af6@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Does "size" have any effect on rendering speed?

No, it is simply a scaling value. The calculation is always there, it 
just usually doesn't do anything.


> Its description sounds like it would define a kind-of bounding sphere.

No...the "radius" keyword is the closest thing to bounding for glows. 
Bounding with a sphere would probably be counterproductive...it would 
probably take longer to find the intersection with a sphere than it 
would to calculate the simpler glows, so "radius" does some of the glow 
calculations and uses their result to decide whether to continue.


>   Well... To me "fade_power 2" looks more realistic than the default
> (exactly for the same reason that a fading light source with fading power 
> 2 is more realistic).
>   So I hope you fix it soon :)

It is not more accurate, and it is very unlikely that it will be 
"fixed", since it does exactly what it was intended to do. In order to 
get any better, falloff calculations will have to be added to the 
individual types.


>   But media is slow and requires a lot more tweaking.

If you want speed and ease of use, use glows. :-)

-- 
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 <chr### [at] maccom> wrote:
:> Its description sounds like it would define a kind-of bounding sphere.

: No...the "radius" keyword is the closest thing to bounding for glows. 

  Oops! You are right. I said "size" but was thinking about "radius". Sorry :)

  But if "size" can't be used, it's even worse. Of course you have to be
able to control the size of the glow.

: Bounding with a sphere would probably be counterproductive...it would 
: probably take longer to find the intersection with a sphere than it 
: would to calculate the simpler glows

  You don't have to use real ray-sphere intersection test for this. It's
enough to test "how far is this point (the center of the glow) from this
line (the ray we are tracing)? If it's closer than 'radius', then proceed
with glow calculation, else just skip it".
  Calculating the distance between a point and a line is simpler and faster
than calculating the intersection of a line and a sphere.
  It might cause some speed improvement, specially when there are lots of
glows.

  Or does it do this already?

:>   But media is slow and requires a lot more tweaking.

: If you want speed and ease of use, use glows. :-)

  But if they are buggy, the result will not be the one I wanted.

-- 
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

In article <39ed836d@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   But if "size" can't be used, it's even worse. Of course you have to be
> able to control the size of the glow.

You can do that now by making the glow brighter or dimmer. In fact, this 
is how the original patch controlled the size...I may revert to doing 
this internally for the first two types.


>   Calculating the distance between a point and a line is simpler and 
> faster than calculating the intersection of a line and a sphere. It 
> might cause some speed improvement, specially when there are lots of 
> glows.
>   Or does it do this already?

That is exactly what it does. But it also affects the resulting 
image...unless you use a large enough radius that there aren't any 
calculations skipped, and no speedup. The two types of glows that are 
fully implemented are infinite, and though individually they fade to 
invisibility beyond a certain distance, when you put a large number of 
them together there is a very visible difference.


> : If you want speed and ease of use, use glows. :-)
> 
>   But if they are buggy, the result will not be the one I wanted.

They don't do what you want, but it is not a bug. The size keyword is 
buggy, but fade_power does exactly what it is supposed to do: it adjusts 
the final results of the glow falloff functions. This causes an 
unrealistic result when reflected or seen through transparent objects, 
but that is not a bug in the feature.

-- 
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

> They don't do what you want, but it is not a bug. The size keyword is
> buggy, but fade_power does exactly what it is supposed to do: it adjusts
> the final results of the glow falloff functions. This causes an
> unrealistic result when reflected or seen through transparent objects,
> but that is not a bug in the feature.

	But Warp mentionned that the result is wrong also when the transparent
object is *behind* the glow, and that's true. He was right when he said that it
might be a problem of ray length (my guess).
	In the Do_Glow code, the scattering depends both on the last intersection
found (Ray->Initial) and the next one (through Depth). I would expect the glow
to depend mostly on the Frame.Camera->Location which distance is constant to the
glow, and not from Ray->Initial that may change due to transparent objects. But
replacing that is not enough, Depth should be corrected also. Yet I didn't find
how. I also wonder how refraction would work...
	Or am I completely wrong ?
	Chris, I'm sure you know the answer ;-)


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

In article <39E### [at] freefr>, Nicolas Calimet 
<pov### [at] freefr> wrote:

> 	But Warp mentionned that the result is wrong also when the transparent
> object is *behind* the glow, and that's true. He was right when he 
> said that it might be a problem of ray length (my guess).

If it shows up even when size(which is buggy) and fade_power(which is 
unrealistic) are not used, then there is a problem with those 
calculations...and I don't fully understand what the equations do or are 
supposed to do yet.


> 	In the Do_Glow code, the scattering depends both on the last 
> intersection found (Ray->Initial) and the next one (through Depth). I 
> would expect the glow to depend mostly on the Frame.Camera->Location 
> which distance is constant to the glow, and not from Ray->Initial 
> that may change due to transparent objects. But replacing that is not 
> enough, Depth should be corrected also. Yet I didn't find how. I also 
> wonder how refraction would work...

If the calculations are changed to depend on the camera location instead 
of the ray starting location, reflected and refracted glows will not 
work at all.

-- 
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

Perhaps the distance used in the calculation should not be taken from
the current ray only, but from the total distance travelled by the ray
sent from the camera (and bounced from reflecting objects or refracted
from transparent objects).
  Or would this be too hard?

  Perhaps better a falloff algorithm that doesn't depend on the ray length.

-- 
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