Warp wrote:


> : bogus happen when one vertex is ON the object.
>
>   I really don't understand why this would be any problem.

I don't either.
Tracing the EDGES of the requested triangles (with some cylinders),
it looks to me like some (the bogus ones...) triangles were connecting
points that were far too apart (at least outside the walking cube).
At least the good part I found is that all the intersections used
were OK (at least for the sphere, they were all on the surface),

>
>   If a vertex is exactly on the surface of the object, it will be considered
> either inside or outside (depending on the inside testing function for that
> specific object). This shouldn't be a problem. There isn't any third mode
> which isn't either inside or outside. The point is either inside or it is
> outside.
>   An adjacent tetrahedron shares the same point and the same insideness of
> that point. It's not like that point was inside for one tetrahedron and
> outside for the adjacent tetrahedron sharing the same point. I can't believe
> that the insideness test for any object would give different results for
> the _exact_ same point in different calls.

I would agree, but I now have lost the thought about why I ever think that
this may be the source of the problem, excepted that I did not like the use
of the Inside function (because it means one may be unable to correctly
tesselate a union with a 'no-inside' component).

>   No, there aren't three modes, just two. A point is either inside or outside.
> The function doesn't return three values, just two. A point that is exactly
> on the surface of the object will be considered one of the two, so I don't
> understand why it should matter.
>

Me neither... With my current tesselating code, I still have a problem to resolve
when a segment of the tetrahedron has more than one point on the surface of the
object (I initially thought only about both vertexes of the segment, but it may be
more complex than I expected, even if it might be acceptable to continue with only
one point (as before) when the first intersection is not one of the extremity.)

>
>   I don't understand how a part of the surface can be missed even if a vertex
> of a tetrahedron is exactly on the surface of the object.
>

With your original code, I do not either.
With the one I did (which remove the use of the inside_* functions),
I know why, but I still have to handle it correctly (it is not only ADDING the
right triangles, but also REMOVING some of the one currently drawn).
If I succeed, the tesselation of a box should be nearly perfect, without
any offset !


>
>   This would make sense if the insideness test function would return different
> values for the exact same point in different calls. However, I can't understand
> why it would do that. That would require some really, really odd implementation
> (like using rand() or something).

They don't !
But when tesselating, the rounding of the coordinates in the ray intersection
sometimes
provides the intersection STRICTLY outside the studied cube.
That's the difference between theoric maths and applied numbers,
that doesn't help the debugging of your approach.

Side note: the initial patch (0.1) is unable to tesselate a blob from 3.1g,
resulting
in a segmentation fault because the tracing code of blob need a private queue which
is
only initialised AFTER the parsing (see povray.c). As tesselating code uses the
intersection function,
the blob structure must be ready before the parsing. Once corrected, it's a
pleasure
to tesselate a blob, with a small accuracy it looks fine, and with a bigger one I
still
have some troubles to fix.

Post a reply to this message