I'm on holiday, so I have more time to play with the tesselation
patch of Warp... and trying to find the bug...

The bug is NOT in:
 - the call of the Inside function of the processed object,
 - the code which generate the mesh of triangles, even if
   the parameters of the function which add a triangle get
   corrupted after the call (It was my favorite candidat)
 - the parsing code.

How do I know ?
I used a different approach, while reusing part of Warp code
(I hope it's ok): instead of launching  a ray to determine
the best intersection point to build the triangle set,
I just call the Inside function for the eight corner of a 
moving cube and draw a surface for each change of value
along the cube lines. The surface is a square (made of triangles),
exactly at the middle of the segment, perpendicular to the segment,
whose surface is a cube face.
The resulting mesh look like a set of small cubes
(just find a way to replace the top/bottom face with a lego bump and it
would legolise anything with an inside, including a sphere or a blob...)

So, my current guess is that the bug in Warp Tesselation patch
must be in the ray-tracing or in the tesselation of the cube/tetrahedron
part.

I posted an animation in p.b.a with a transformation applied to
a tesselated box. Initially, the transformation was done in the
pov-script,
but it took so much time to parse (just applying a while loop to
about 60 000 triangles, getting each vertex and transforming them before
adding a new triangle in a new mesh), that I hard-coded/extended in 
povray the screwing as well as the rolling transform.

Post a reply to this message