In article <chr### [at] netplexaussieorg>,
 Christopher James Huff <chr### [at] maccom> wrote:

> Well, the method I'm considering with my own raytracer is to just forbid 
> overlapping transparent objects. After a ray enters a shape, the tracer 
> will only test against that shape until it exits again. Things will be 
> arranged so that each shape only has one material, so it won't enter 
> through a surface with one material and exit through one with a 
> different material. Non-refracting objects would be exempt from this, it 
> would be very undesireable for media containers.

Another problem with this: transparent objects inside other transparent 
objects, like a glass marble in a pool of water. It would also make the 
pool of water more difficult.

I think the only solution is to do something like what POV does and just 
say that partially overlapping objects won't render correctly because it 
is impossible to say what the "correct" way is. A render-time warning 
might be helpful sometimes, but would usually be useless overhead.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Sun, 21 Jul 2002 20:28:17 +0200, Micha Riser wrote:
> IMO it is a bug in POV-Ray. The ray passes through the box and is refracted 
> when it leaves it. That means it is refracted even though the ior before 
> the hit and after the hit both are 1.0.

Careful what you call a bug.  You seem to be concerned that POV-Ray does 
something unrealistic when you present it with a situation that cannot exist
in reality.  Why is this a problem?

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

Ron Parker wrote:
> 
> Careful what you call a bug.  You seem to be concerned that POV-Ray does
> something unrealistic when you present it with a situation that cannot
> exist
> in reality.  Why is this a problem?
> 

I called it a bug because ior has been moved from finish to interior 
because ior has to be constant in the whole object to prevent that a ray 
enters at one ior and leaves at a different one. But when two object of 
different ior are merged / intersected exactly the same thing happens. 

I see now that overlaping of transparent object in union cannot be checked 
at parsing time and checking it during rendering would things slow down. 
But in the case of merge/intersection a warning at parsing time could be 
issued.

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
>
> Careful what you call a bug.  You seem to be concerned that POV-Ray does
> something unrealistic when you present it with a situation that cannot exist
> in reality.  Why is this a problem?
>

Something about the above statement, even though I understand it, makes my brain
hurt.

Post a reply to this message

Christopher James Huff wrote:
> 
> Another problem with this: transparent objects inside other transparent
> objects, like a glass marble in a pool of water. It would also make the
> pool of water more difficult.

Well, it could still be done by cutting the space for the marble out of the 
water. But with too many cuts out the performance gain would be lost.

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

In article <3d3ed0da@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> I called it a bug because ior has been moved from finish to interior 
> because ior has to be constant in the whole object to prevent that a ray 
> enters at one ior and leaves at a different one. But when two object of 
> different ior are merged / intersected exactly the same thing happens. 

There isn't really any way around that. At least it is an improvement.
One thing that has been bothering me is the "glass of water" type 
situation...I'm not sure POV handles it correctly or how to model it 
correctly.


> I see now that overlaping of transparent object in union cannot be checked 
> at parsing time and checking it during rendering would things slow down. 
> But in the case of merge/intersection a warning at parsing time could be 
> issued.

It is no more possible in those cases than it is in a union. They would 
have to be checked at render time just like unions.
The best you could do is check if the bounding boxes overlap and give a 
"possible overlap" warning if more than one object is transparent, but 
that would happen so often it would be completely useless.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
> Another odd little trick I've been wanting to try: normally, when you
> hit a surface like glass, you have to trace a refracted ray and a
> reflected ray. With many transparent objects, this can create a lot of
> rays very quickly.
> The trick would be to randomly choose refraction or reflection. The rays
> would never "branch", they would just take a random path through all the
> possible paths. You would then take several samples for each pixel, each
> sample would take a different path and you would get a fair
> approximation for the pixel without tracing every single ray. I have no
> idea how well this would actually work, but it seems like an interesting
> idea.

But how would you combine the sample values to the final value? Average 
would be much too dark. Sum of course depends on the number of samples.. 
One would kinda have to estimate the number of all possible paths by 
measuring the samples trace depth and then mulitplicate the average by that 
number.

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

"Micha Riser" <mri### [at] gmxnet> wrote in message
news:3d3ed209@news.povray.org...
> Christopher James Huff wrote:
> >
> > Another problem with this: transparent objects inside other transparent
> > objects, like a glass marble in a pool of water. It would also make the
> > pool of water more difficult.
>
> Well, it could still be done by cutting the space for the marble out of
the
> water. But with too many cuts out the performance gain would be lost.
>
> - Micha

Doing this, you essentially increase the number of surfaces as you can't
have coincidental surfaces.

-tgq

Post a reply to this message

> One thing that has been bothering me is the "glass of water" type
> situation...I'm not sure POV handles it correctly or how to model it
> correctly.
>

Here it is necessary to double up your surfaces so the surface of the water
is slightly outside the surface of the glass. ie, the ray exits the glass
into air and then into the water.  There is no way to avoid increasing the
number of surfaces in this case if you want it to work correctly. For
something completely immersed int the water (or glass for that matter) this
isn't necessary (in case you think this is contradicatory to my previous
post).

-tgq

Post a reply to this message

Christopher James Huff wrote:
> One thing that has been bothering me is the "glass of water" type
> situation...I'm not sure POV handles it correctly or how to model it
> correctly.

AFAIR the discussions about this problem the suggested why to do this is 
make the water overlap the glass. Because leaving a space between will 
cause multiple reflections. However I don't know if the overlaping is 
handled as wished in that case.

>> I see now that overlaping of transparent object in union cannot be
>> checked at parsing time and checking it during rendering would things
>> slow down. But in the case of merge/intersection a warning at parsing
>> time could be issued.
> 
> It is no more possible in those cases than it is in a union. They would
> have to be checked at render time just like unions.
> The best you could do is check if the bounding boxes overlap and give a
> "possible overlap" warning if more than one object is transparent, but
> that would happen so often it would be completely useless.

It is in the nature of merges to overlap.Otherwise you could just as well 
use union. It is even more in the nature of intersection memebers to 
overlap ... otherwise you have a null object. So it would be natural to 
assume at parsing time that merge/intersection do overlap and always issue 
a warning when iors are different.

So forcing merge/intersection to have one single ior would not make the sdl 
weaker because in that case where the merges do not overlap the user should 
have used union anyways.

- Micha


-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message