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

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

An alternative would be to allow objects be (compleatly) inside another. So 
that the water object would have a list of its 'internal' objects. Tracing 
ray inside the water would then only test for these interal objects and the 
water container. Outside the water the interal objects would not have to be 
considered.

- Micha

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

Post a reply to this message

In article <3d3ed209@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
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.

It wouldn't be a good solution. The interface between glass and water 
should be a single surface, with two they would have to either overlap 
or leave an air gap to avoid coincident surface problems. Overlap = bad, 
air gap = an entirely different situation from the one being simulated. 
Better to just say that if you are entering the marble you are exiting 
the water. But when you exit the marble, what do you exit into? Could be 
air, could be water...just check to see if the point is still "inside" 
the water object?

If you can guarantee that the marble is completely immersed, a ray could 
just check each surface against the last surface it hit to detect an 
exit, but if it pokes through the surface...similar to the "glass of 
water" situation.

Maybe a new type of "immersion" CSG would be helpful, some kind of 
half-merge: surface A (water) does not exist inside surface B (marble), 
but surface B does exist inside surface A.
immerse {
    FLUID_OBJECT
    IMMERSED_OBJECTS
}

Maybe separate ior entirely from the surfaces...say "this area of space 
has glass ior, this area has water, everything else has air". Whenever a 
surface is hit, check the ior at a tiny distance to each side. I don't 
really like this solution, but I think it would work.

Maybe at the CSG stage, the ior on each side of the surface could be 
computed and saved...

immerse {
    Water
    GlassCup
}

 ___ air ___
|g _|___|_  |
|l| |wat| | |
|a| |er | | |
|s| |___| | |
|s|_______| |
|___________|

A ray entering through the side of the glass and exiting either through 
the water (a) or the other side of the glass (b):
1: Start in air, hit the glass surface.
2: Hit the water surface, ignore because still inside glass object, but 
set "containing medium" to the water object.
3: Hit the glass surface again, exit to containing medium (the water).
4a: Hit the water. It is the containing medium, so exit into the next up 
medium (air).
4b: Hit the glass again, go from containing medium (water) to glass.
5b: Hit the water surface, inside glass so ignore, but exit containing 
medium to next up (air).
6b: Hit the glass surface, exit to containing medium (air).

This would require the immerse CSG, but it would work in every 
(realistic) situation I've thought of.

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