Honest this is not a feature request.

I was curious as to why POV doesn't solve the problem of c.s. surfaces.

What are the difficulties of implementing, or the disadvantages of having
some sort of automatic precedence?

so...

union{
    box{0,1}
    box{0,2 translate y*1}
    pigment{White}
}

would resolve in order of listing, with the c.s. of the first box "beating"
the c.s. of the second box.

In the above example (and in many RLCoding situations) it doesn't make any
difference anyway, since the material is the same for both.

just curious ...

Post a reply to this message

Tom Melly wrote:
> 
> Honest this is not a feature request.
> 
> I was curious as to why POV doesn't solve the problem of c.s.
> surfaces.

<snip>

> In the above example (and in many RLCoding situations) it doesn't make
> any difference anyway, since the material is the same for both.

In the situations where it does matter, it is very simple to model
so that the surfaces no longer coincide, but still achieve the desired
effect.

In other words, the problem went unsolved because the need to solve it
is not very urgent.

-- 
ICQ: 46085459

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
: What are the difficulties of implementing, or the disadvantages of having
: some sort of automatic precedence?

  The problem is that povray has no way of knowing that two surfaces are
exactly in the same place.
  How could it know it? When it gets the intersection points of the ray
and two objects and even when these points are very close to each other,
it still can't decide that "these surfaces are coincident". The surfaces
may just be intersecting and the current intersection point happens to be
really close to their intersection line.
  It can't do that even if the normal vectors are (almost) identical because
the normals just happen to be perturbed so that they happen to be really
close by chance.
  And how can it know that one of the surfaces is not truely in a different
(though very close) place than the other surface and that it's not just an
accuracy thing?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3c5b0ee1@news.povray.org> , "Tom Melly" <tom### [at] tomandlucouk> 
wrote:

> What are the difficulties of implementing, or the disadvantages of having
> some sort of automatic precedence?

The coincident surface problem is exactly this.  Ray-tracing works by what you
call "automatic precedence", that is sorting the intersections found.
However, when a surface is at "exactly" the same place the intersections don't
really have to be and mostly are not because the precision available is
limited and causes some intersections to appear slightly closer than others.
As this effect changes from ray to ray, you see the coincident surface
problem.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Tom Melly wrote:

> What are the difficulties of implementing, or the disadvantages of having
> some sort of automatic precedence?

I think the problem is that Pov is not aware the the surfaces coincide. 
Due to the limited precision of the calculations, it sometimes 
calculates one of the surfaces to be in front, sometimes the other, so 
there is never any question of which one has precedence.

/Ib

Post a reply to this message

On Sat, 02 Feb 2002 10:55:45 +0100, "Thorsten Froehlich" <tho### [at] trfde> wrote:
> In article <3c5b0ee1@news.povray.org> , "Tom Melly" <tom### [at] tomandlucouk> 
> wrote:
> 
> > What are the difficulties of implementing, or the disadvantages of having
> > some sort of automatic precedence?
> 
> The coincident surface problem is exactly this.  Ray-tracing works by what you
> call "automatic precedence", that is sorting the intersections found.
> However, when a surface is at "exactly" the same place the intersections don't
> really have to be and mostly are not because the precision available is
> limited and causes some intersections to appear slightly closer than others.
> As this effect changes from ray to ray, you see the coincident surface
> problem.
> 

This may be a completely stupid question... But couldn't it be set up so that the user
can specify a precedence in cases where these things do happen? If the
user could overide the automatic precedence sorting I would think the problem
would disappear. It could be made to effect only the next object in a CSG or
something,
so that only those objects effected by it are overided.

Post a reply to this message

In article <1103_1012681210@selliot> , Patrick Elliott <selliot@rraz.com> 
wrote:

> This may be a completely stupid question... But couldn't it be set up so
> that the user
> can specify a precedence in cases where these things do happen? If the
> user could overide the automatic precedence sorting I would think the problem
> would disappear. It could be made to effect only the next object in a CSG
> or something,
> so that only those objects effected by it are overided.

It is a stupid question:  You are suggesting exactly the same I answered won't
work.  Try to read the explanation again...

    Thorsten

Post a reply to this message

On Sat, 02 Feb 2002 22:29:47 +0100, "Thorsten Froehlich" <tho### [at] trfde> wrote:
> It is a stupid question:  You are suggesting exactly the same I answered won't
> work.  Try to read the explanation again...
> 

I did read it again.. According to your description the raytracer 'automatically
sorts' the
surfaces on a 'ray by ray' basis... Ok. So how does telling the renderer that in case
of objects
A, B and C you should always assume that B has precidence when it is some really small
distance from A and C? If the difference in spacing is so small that it creates
coincident
surface problems, it is unlikely that the resulting behavior would be worse than it is
now, if the
raytracer was forced to assume that they do in fact occupy the same space or that one
of
them should 'always' be interracted with first. I don't get why forcing such a thing
is 'impossible'.
Of course it may be impossible using the current implimentation, but that doesn't mean
it is
completely impossible to do.

Of course as you said, it is easy to fix without doing such a thing, if a tad
inconvenient in some
cases. ;)

I do admit though that I am not an expert, so could be flat out wrong, but so can
experts sometimes.

Post a reply to this message

On Sat, 02 Feb 2002 20:20:10 GMT Patrick Elliott wrote:

>But couldn't it be set up so that the user
>can specify a precedence in cases where these things do happen?

  This is already possible using POV-Ray - simply scale or translate
slightly and the problem is solved because coincident surfaces no longer
exist! This is the easiest and *best* method of dealing with coincident
surfaces.

  If someone wants to write a patch to establish a user-specified (phony
ordering) precedence, then by all means they can do so and it can prove its
worth in a custom version of POV-Ray.

-- 
Alan
ako### [at] povrayorg
a k o n g <at> p o v r a y <dot> o r g

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3c5bb65a@news.povray.org...

<snip>

Thanks Warp and Thorsten - that makes sense. I was fairly sure it was a stupid
question, I just couldn't work out why.

Post a reply to this message