Le 18/08/2016 à 18:49, clipka a écrit :
> Am 18.08.2016 um 18:13 schrieb clipka:
>> As for the union of individual triangles, I'm still working on that one;
>> I must confess that so far I don't really have a clue where things go wrong.
> 
> Yikes!
> 
> I've found the culprit.
> 
> 
> You see, after parsing the triangle vertices, POV-Ray invokes a piece of
> code that precomputes certain values for the triangle that will be
> required in each and every intersection test.
> 
> That code first computes the surface normal from the vertices, as well
> as the distance between the coordinate origin and the plane in which the
> triangle lies.
> 
> The code then goes on to enforce a certain ordering of vertices that
> allows for certain shortcuts in intersection testing. You may note that
> this shouldn't be a problem for the interior/exterior texture test,
> since the surface normal has already been computed at this point.
> 
> 
> It /does/ become a problem, however, as soon as you invoke any
> transformation on the triangle -- because such an operation changes the
> position of the vertices, and therefore requires a re-computation of the
> precomputed stuff.
> 
> And this time the precomputation will operate on potentially rearranged
> vertices.
> 
> 
> As I said: Yikes!
> 

Nicely spotted, and it applies only to triangle outside a mesh.

Nevertheless, aside from passing the swapped status during computation of data, do we
really need to store that bit in each triangle ?
(moreover, in something not "unsigned int :1", which might actually extend the size of
the Triangle structure)

And did you check the SmoothTriangle::Compute_Triangle ?
Similar code with extra swapping of normal at vertices, yet the Normal_Vector is the
same old way as Triangle::Compute_Triangle.

Post a reply to this message