Face Me

toxicvoxel

A face created with points running in a counter-clockwise direction in a plane should create a face with the normal pointing in the Z direction of the plane.
This seems to work in most cases but sometimes the entities_addface function appears to rearrange the vertexes as the code samples below illustrate. Can anybody explain why this is happening?

'==================================== A
def makeface_counterclockwise __model = Sketchup.active_model __entities = __model.entities pts=[] pts[0]=[0,0,0] pts[1]=[50,0,0] pts[2]=[50,50,0] face = __entities.add_face pts puts "--------------face.vertices" face.vertices.each {|vx| puts vx.position} end

This code returns vertexes that have been re-arranged resulting in incorrect orientation :
--------------face.vertices
(50", 0", 0")
(0", 0", 0")
(50", 50", 0")

'==================================== B
def makeface_clockwise __model = Sketchup.active_model __entities = __model.entities pts=[] pts[0]=[0,0,0] pts[1]=[-50,0,0] pts[2]=[-50,50,0] face = __entities.add_face pts puts "--------------face.vertices" face.vertices.each {|vx| puts vx.position} end
This code return expected results:
--------------face.vertices
(0", 0", 0")
(-50", 0", 0")
(-50", 50", 0")

'==================================== C
def makeface_counterclockwise_vert __model = Sketchup.active_model __entities = __model.entities pts=[] pts[0]=[0,0,0] pts[1]=[0,0,50] pts[2]=[0,50,50] face = __entities.add_face pts puts "--------------face.vertices" face.vertices.each {|vx| puts vx.position} end

This also returns expected results but contradicts the behaviour in A:
--------------face.vertices
(0", 0", 0")
(0", 0", 50")
(0", 50", 50")

Chris Fullmer

SketchUp is hard wired to always make faces drawn on the groundplane face downwards. So the first example is correct, it should face upwards, but SU over-rides that and orients it to face downwards.

The second example works because you have drawn the face in such a way that it will already point downwards, so SU does nothing to it.

The third example works as expected, because the face is not on the groundplane, so SU does nothing to it.

You will need to always test for that and check the orientation of faces drawn on the groundplane.

Chris

toxicvoxel

Thanks for your response Chris.
The choice of system logic seems peculiar given the overhead that it creates if every face needs to be checked on iterating through a large collection of faces, for example when importing geometry from other file formats.

Chris Fullmer

I wonder if Polygon Mesh works around this:

http://code.google.com/apis/sketchup/docs/ourdoc/polygonmesh.html

Perhaps importing as a mesh will make SU not re-orient any faces? I've not tested it.

thomthom

hm... good question... I'm hoping it does not have this special ZeroZ rule.

But in any case, I highly recommend using a PolygonMesh for any importer, it's by far the quickest way to add mesh to a model. Though, you don't have the control to add material per face, only per mesh.

toxicvoxel

I looked at .add_faces_from_mesh before (which does not follow the 'ZeroZ' rule by the way), but because it has poor support for controlling individual outer (naked) edges of the mesh it's use is limited. If you have to iterate through the entities collection anyway to find and set individual edges it completely negates the efficiency of the method.

Is it just me or is the documentation fraught with errors? The method does not return a collection of faces as stated:

Syntax
faces = entities.add_faces_from_mesh polygonmesh
Arguments
polygonmesh - a Polygon mesh object
Return Value
faces - an array of Face objects if successful

thomthom

@toxicvoxel said:

Is it just me or is the documentation fraught with errors?

It's not you. Basically - look at the API documentation as a guideline - all too often it's wrong. And look for comments at the bottom of the pages.

toxicvoxel

Looking into it further it turns out that add_face on the ground plane appears to re-organise vertexes using rules which would be complex and time consuming to test if vertex indexes are required to set edge visibility. A possible workaround would be to create a temporary group , add 10 to the z values of the face vertexes and then transform the group to the correct position where it can be exploded.

The problem with the Ruby API is that it requires so many hacks & workarounds. It would be in Google's interest to open the API development source so that it can be corrected where necessary and extended to address shortfalls. It is difficult to accept that errors in 7.x documentation remains uncorrected in 8.0.

thomthom

What makes it more troublesome is that the documentation doesn't mention bugs that appeared in the various methods in the various SU versions.