Vertex ordering problem

[devilreborn]

Hi all
I was trying to create a exporter for Sketchup to the .X format, where defining a face requires giving the vertices surrounding that face in clockwise order. After some experimenting I found that Face.vertices is usually given in counter-clockwise order so I made my exporter to output face vertices in reverse of the order given by Sketchup.

The selected object in the following picture is a component with 4 faces, in which I have labelled the vertices of one of them. According to the above logic, the vertices should be given in the order A -> B -> D -> C, so that my exporter would output it as C -> D -> B -> A. (assuming A is the starting vertex)

However the .X file showed the face in the wrong direction. Using the Ruby console I found that Face.vertices of that face is given in C -> D -> B -> A which is already clockwise.

It appears that this component has been flipped along the X axis before, which is likely to be causing the problem.

Is there a way that I can ensure what order will the vertices of a face be listed regardless of transformation?

[tt_su]

I think normally in 3d applications polygons are defined counter-clockwise. This is the case with SketchUp. However - this also depend if the face is reversed. You want to inspect the loops of the faces:
http://www.sketchup.com/intl/en/developer/docs/ourdoc/loop
http://www.sketchup.com/intl/en/developer/docs/ourdoc/face#loops
http://www.sketchup.com/intl/en/developer/docs/ourdoc/face#outer_loop

The Loop objects will return the vertices in order for each loop. If you dig into face.vertices directly they will represent multiple loops if the face has holes.

[devilreborn]

I did try inspecting the vertices of Face.outer_loop although it gave me the same result as Face.vertices. I think the problem is about the orientation of that component since it is horizontally flipped.

Actually is it possible to "temporarily" explode all the components and groups but at the same time not affecting the model (like not ACTUALLY exploding the groups)? I apologize if I didn't express this well enough but I sort of did something like that when I wrote a similar exporter for Blender.

[tt_su]

@devilreborn said:

Actually is it possible to "temporarily" explode all the components and groups but at the same time not affecting the model (like not ACTUALLY exploding the groups)? I apologize if I didn't express this well enough but I sort of did something like that when I wrote a similar exporter for Blender.

Exploding would be incredible slow and would be a clunky brute force way to solve it. You can probably keep track of the transformation hierarchy when you traverse the model and inspect the transformation for when you need to reverse the vertex ordering.

Or ... I assume you are discarding group and instance hierarchy and export a mesh with everything in the same context? Then you can perhaps calculate the vertex winding based on the global position of the vertices at this point. Though I suspect the first method of inspecting the transformation matrix (which you need anyway to get the global position) will be faster.

[tt_su]

I posted on StackOverflow some time ago a snippet to detect if a transformation is flipped or not:
http://stackoverflow.com/a/17982272/486990

[tt_su]

Do you have a sample model to share by the way - just so that we have the same data set to talk over. These types of discussions often become confusing because one inadvertently talk about different things.

[devilreborn]

Thank you for your information,

If I am not mistaken the vertices are arranged counter-clockwise (right-handed system) if it has not been flipped / it has been flipped by an even number of times;
or clockwise (left-handed system) if it has been flipped by an odd number of times. In other words I can make use of the cross product of the component's local axes (from the transformation matrix) to determine which direction vertices are arranged.

At least that is how I think it works. Please correct me if I am wrong.

BTW attached is the model in the screenshots above.
track.skp

[tt_su]

We actually had this issue with the STL exporter. STL doesn't have object hierarchy so we must export everything into one big mesh.
See issue here:
https://github.com/SketchUp/sketchup-stl/issues/129

Then I think the commit that fixed was this one:
https://github.com/SketchUp/sketchup-stl/commit/4ad199a2d46245f2a668e47f2ee81bc36c9b9763