On Wed, 28 Oct 1998 14:59:59 -0500, Nathan Kopp <Nat### [at] Koppcom> wrote:
>Bezier patches are also infinitely thin.  It MIGHT be possible to create a
>patched version of POV that treats triangle meshes as solid.  The main
>problem that currently exists is that POV doesn't know if a point is inside
>an object or not.  The simple (but not always effective) solution is to
>shoot an arbitrary ray from the point and if it intersects an even number
>of triangles, you are outside the object, and if it intersects an odd
>number than you are inside.  Maybe I'll try it.  (here I go again talking
>about stuff here that should be in the povray.programming newsgroup.)

Welcome to the club, Nathan.  I'm guilty of posting about programming stuff
here as well.  Something you'll want to keep in mind is that if you 
intersect at a vertex or edge, you'll have to either shoot a new ray or use 
some heuristics to determine whether the edge or vertex counts as an 
intersection or not.  That is, if you shoot a ray "tangent" to a vertex or 
edge, you don't want to count the intersection.  If you shoot it "through" 
a vertex or edge, you want to count it, but only once (more than one 
triangle could be hit at such a point, but you only want to count one.)

Followups set to povray.programming.

Post a reply to this message

Ron Parker wrote:
> if you shoot a ray "tangent" to a vertex or
> edge, you don't want to count the intersection.  If you shoot it "through"
> a vertex or edge, you want to count it, but only once (more than one
> triangle could be hit at such a point, but you only want to count one.)

I think I know what you mean, but just in case.....

Consider a prism of vertices

<0,  -1, 0>
<-1, -1, 1>
<-2, -1, 0>
<-1, -1, -1>
<0,   1, 0>
<-1,  1, 1>
<-2,  1, 0>
<-1,  1, -1>

A ray along the z axis is perpendicular to an edge (not tangent),
yet the intersection must be counted either 0 or 2 times, as
the ray never penetrates the object surface.

Further, I am not sure what you mean by tangent to a
vertex, as a vertex is just a single point, and thus all
intersections are equivalent.

But your general point is excellent -- the intersection determination
is highly non-trivial.

Furthermore, open objects don't have a well-defined interior,
so care is needed to make sure the object is a "solid" object....
if it is formed by nondegenerate CSG, this is of course
guaranteed.

Dan



-- 
http://www.flash.net/~djconnel/

Post a reply to this message

On Wed, 28 Oct 1998 19:35:26 -0600, Dan Connelly <djc### [at] flashnet>
wrote:

>Ron Parker wrote:
>Further, I am not sure what you mean by tangent to a
>vertex, as a vertex is just a single point, and thus all
>intersections are equivalent.

Ah, this is why I put "tangent" in quotes.  There is, of
course, no tangent to a discontinuity, but all intersections
are not equivalent.  (warning: ugly ascii art ahead)

  \             \   /
   \             \ /
- - X - - - - - - Y - - - -
   /
  /   

Pretend the horizontal line is a ray.  The intersection on the left
should be counted, the one on the right not.  Determining which is
which in 3D is left as an exercise for the reader.

>Furthermore, open objects don't have a well-defined interior,
>so care is needed to make sure the object is a "solid" object....
>if it is formed by nondegenerate CSG, this is of course
>guaranteed.

Actually, there are closed surfaces that don't have well-defined
interiors, as well, though they self-intersect so they are detectable
(painfully.)

We're allowed to use open cylinders and prisms in CSG, despite the
fact that they don't behave.  Why should determining the suitability
of a mesh fall on the POV programmers?  Why not on the people making
the scene?

Post a reply to this message

I have implemented a simple version of the solid mesh in my patched
version of POV (soon to be released).  It worked well with the very
few meshes that I have thus-far tested it with.

Ronald L. Parker wrote:
> 
> 
>   \             \   /
>    \             \ /
> - - X - - - - - - Y - - - -
>    /
>   /
> 
> Pretend the horizontal line is a ray.  The intersection on the left
> should be counted, the one on the right not.  Determining which is
> which in 3D is left as an exercise for the reader.
> 

These are good points which I thought of but simply ignored in the current
implementation.  The case on the left can be solved by keeping track of
all of the intersections and removing any duplicates (so that such a case
would not be counted twice).

The case on the right is a much more difficult problem.  Fortunately, it
will not occur very often.  But that's not a good excuse.

My current solution is to allow the user to choose the direction of the
sample ray.  This allows even misbehaved objects to work fine if an
appropriate direction is found.

-Nathan Kopp

Post a reply to this message