Ron Parker wrote:
> 

> >All questions are allowed... Even "How many angels can dance on the head of a pin
?"
> >Getting the correct answer might be harder.
> >
> >The code for inside and trace is always different (by design).
> >I guess that different algorithms can give different results.
> >(Just look at the sturm solver option for example)...
> 
> My guess would be that you're running afoul of the provisions in all of the
> intersection code that throw out intersections that are too close to the
> start of the ray.

Maybe, Maybe not. That aspect was already taken care of in the initial patch by
making the start point of the ray a little more on the outside that it would
have
been needed to if only the segment to test was really done.

There is two things in my posting of a solution:

 1. Where the bug manifest itself, and why.
 2. How to correct that.

Point 2 is probably open to wide discussion (and holy war). 
    As Warp is the author of the patch, he is the one to choose.

Point 1 is hard-fact, and now that it has been found, it is easy to
demonstrate (just put a dirty "printf" before the Intersection() call,
 and another in the "then" part of the "if" that is testing the return value
of Intersection; If the assumption of design was correct, you should get
the same number of first printf than of the second; Alas, take any bogus scene
and you will see that there is more of the first!(*)
As provided, the intersection should have been tested.

My correction was to "Add the test and an else behaviour", because it
was simpler to implement and easier to prove.
Another possible may have been "Fix the parameters of Intersection so
that the problem never occurs again", which seems to me to be harder
to implement and probably impossible to prove.
A third solution was also "Fix the insideness structure on the fly so
that no tesselation of that tetrahedron will occurs", which seems a good idea
if one wants to have some goto in the code. Moreover, it may have opened a
tricky flickering case in which we would be in an infinite loop.


(*): If you do not like printf, you can simply have a ++/-- on a counter.
By the end of the tesselation, it should have been as it was before.
It will not with a bogus scene. So, you may even have a detection of the bogus
scene and have the tesselation failed at parse time, if you want.
I find that approach a little too much hostile, because the user has probably
no way to make the scene works correctly, other than playing randomly with
the tesselation parameters...

Post a reply to this message