[x3d-public] TriangleStripSet and ccw

[Alekseyev, Vsevolod (NIH/NIAID) [E]]

While we're on the topic of standard ambiguities, here's another issue.

Imagine a TriangleStripSet. It has a sequence of points with a sliding window logic to them - the first triangle is points 0, 1, 2, the second is 1,2,3, then 2, 3, 4, etc. It's illustrated perfectly at http://www.web3d.org/documents/specifications/19775-1/V3.3/Images/TriangleStripSet.png

The element also has a ccw flag that tells us which side of the triangle is the outer side.

Now, the issue. If the ccw logic is to be followed *for every triangle*, every second triangle would look the other way from the previous one.

Look at the image. For the first triangle, the logic for determining the outer side is - if you look at the triangle from the outside, vertices 0, 1, 2 should go counterclockwise. But if you look from the same vantage point at the second triangle, vertices 1, 2, 3 would go *clockwise* instead. Were the algorithm to go by the strict letter of the ccw rule, one would have to conclude that odd numbered triangles in the strip look one way, even numbered ones look the other way.

Fortunately, few implementors think so. Neither X3DOM nor X3D-Edit read the standard that way. My Blender X3D importer flips the vertex order for every odd triangle, too. The only implementation that does not is meshlab. Upon rendering, it gives a very characteristic "checkerboard" pattern - triangles that are seen from the inside are dark.

The same issue would obviously plague IndexedTriangleStripSet, but not [Indexed]TriangleFanSet.

Maybe a clarification in the standard would be in order, that ccw only applies to the *first* triangle in the strip, for the subsequent ones one should go by consistent orientation of adjacent triangles.

Vsevolod "Seva" Alekseyev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150824/6f273739/attachment.html>