POV-Ray : Newsgroups : povray.pov4.discussion.general : Solution to coincident surfaces Server Time
28 Mar 2024 08:36:04 EDT (-0400)
  Solution to coincident surfaces (Message 1 to 3 of 3)  
From: Tim Attwood
Subject: Solution to coincident surfaces
Date: 3 Jul 2009 19:43:03
Message: <4a4e9787$1@news.povray.org>
If during parse the order that objects are added
is preserved (by adding an index possibly), then 
later when they're being traced against, check the 
objects in the current bounding slab in that order.
That way a coincident surface will always return
the same texture, the one from the object that was
encountered first during parse.


Post a reply to this message

From: Warp
Subject: Re: Solution to coincident surfaces
Date: 3 Jul 2009 20:10:43
Message: <4a4e9e02@news.povray.org>
Tim Attwood <tim### [at] anti-spamcomcastnet> wrote:
> If during parse the order that objects are added
> is preserved (by adding an index possibly), then 
> later when they're being traced against, check the 
> objects in the current bounding slab in that order.
> That way a coincident surface will always return
> the same texture, the one from the object that was
> encountered first during parse.

  The problem is not deciding which surface to choose, but detecting
the coincident surfaces. Even if you consider surfaces which are "close
enough to each other" as coincident, there may be situations where they
are still not detected. For example, if the two objects are in different
branches of the bounding box hierarchy and their bounding boxes don't
overlap, the other object might be completely skipped from consideration
if the first object was hit.

  It can also cause interesting problems with transparent surfaces.
Basically you would be removing one of the coincident surfaces, and
which one is removed depends on the direction of the ray.

-- 
                                                          - Warp


Post a reply to this message

From: Tim Attwood
Subject: Re: Solution to coincident surfaces
Date: 4 Jul 2009 05:37:02
Message: <4a4f22be$1@news.povray.org>
"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4a4e9e02@news.povray.org...
> Tim Attwood <tim### [at] anti-spamcomcastnet> wrote:
>> If during parse the order that objects are added
>> is preserved (by adding an index possibly), then
>> later when they're being traced against, check the
>> objects in the current bounding slab in that order.
>> That way a coincident surface will always return
>> the same texture, the one from the object that was
>> encountered first during parse.
>
>  The problem is not deciding which surface to choose, but detecting
> the coincident surfaces.

Right, you trace against all the objects inside the bound, that means
that if a new ray-object instersect test is less than epsilon shorter
than the previous shortest ray-object instersect test then you need
to preserve it in a list. The way it is now that hit is discarded
if the new hit is shorter at all, so you see the FP rounding errors.

> Even if you consider surfaces which are "close
> enough to each other" as coincident, there may be situations where they
> are still not detected. For example, if the two objects are in different
> branches of the bounding box hierarchy and their bounding boxes don't
> overlap, the other object might be completely skipped from consideration
> if the first object was hit.

If they aren't in the same bounding slab then it'll obviously not
trace against the other object. I guess that means that the bounding
boxes would need to be 1-2 epsilon bigger than the objects to avoid
that.

>  It can also cause interesting problems with transparent surfaces.
> Basically you would be removing one of the coincident surfaces, and
> which one is removed depends on the direction of the ray.

I don't see that, the one selected would be the one first in SDL
at parse, not the first one the ray hit. Though you are right that
there really would still be coincident surfaces, they just wouldn't
be speckled.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.