KalleK wrote:
> 
> I can reacreate the bug.
> don't use sturm, but D = 1.58113883008418,
> to get to the limit between visible and unvisible.
> 
> Athlon 1,4GHz, 512MB DDR RAM Win98
> 
> cukk

Playing with the scene file and 3.1g (it happen here too!),
the bug can be push away when playing with the
SMALL_ENOUGH constant in polysolv.c 
(Going from xE-10 to xE-30 give the correct picture for D=2)

The reason seems to be that the root solver decide to reduce
the order of the equation (normaly 4) when the first
coefficient is small enough (when D > 1.58.., it try
to resolve an order 3 equation.). 
Preventing that behavior by bursting the value of SMALL_ENOUGH
is one way to resolve that bug. 
Another way could also be to normalise the computed coefficients
of the blob so that the size of the interval always be the
same order of magnitude, instead of using always a unit vector.
But It might be difficult to correctly perform that modification,
and it may impact the precision of the blob intersection.
(because, back from the root solver, it will be needed to transform
back the intersection in the original space).

I wonder if there is really a need for automatically reducing the order of the
equation,
excepted for speed on nearly trivial case ?

Post a reply to this message