API Wishlist – another method similar to add_face

Developers Ruby API
1

I recently revisited some import code I have and took a look at the am.entities.add_face method. It seems that face orientation is dependent on where the face is drawn and what existing faces it connects to.

If the face is drawn free of other faces and away from any of the x, y, or z axes, it is drawn with the face normal obeying the right-hand-rule (RHR).

It would be very helpful if the Ruby API had an additional method –

entities.add_face_rhr

that would create a face where the normal always followed the RHR.

Thanks,

Greg

2

You can of course get the resultant new face.normal and reverse that new face if it’s not oriented to your requirements.

One thing to bear in mind is that if the face is draw at z=0 and it is also ‘flat’ [i.e. face.normal.parallel?(Z_AXIS)], then irrespective of the face’s loop’s vertices ‘clockwise-ness’ it is always going to be made facing downwards - just like a manually made face that is flat on the ground also looks downwards as it’s assumed that you want to PushPull it upwards…
So if you have drawn any face in that location/orientation then [depending on what you want to do with it] you might want to reverse it so its normal is ‘upwards’, before doing the next step ?

3

TIG,

Thanks. I’m aware of the issues when adding faces in the x-y plane. Have you ever checked to see if the same thing occurs in the other planes? I have not…

What’s even worse is that when adding horizontal faces not on the x-y plane, SU will reorient them depending on the orientation of the existing faces they adjoin. IOW, the model will change depending on what order the faces are added in. That’s just wrong.

I suppose I could determine the bounds of the data I’m importing, then add all the faces ‘out in space’ (where they don’t intersect with anything), then move them to their correct location. That’s a PITA.

Hence, the reason for my suggestion. Obviously, the code exists to determine face direction, as that is how ‘free faces’ are added when not on the x-y plane. Also, as you may know, add_face really slows down as the number of faces grows. I can’t help but wonder if that slow down is due to the ‘inference engine’ being used to determine orientation.

Would you like the API to have the additional method?

Thanks,

Greg

4

Yea, the face orientation “magic” is some times confusing and undesired.

You might have more luck with using Geom::PolygonMesh. Have you tried that? (Usually much faster than add_faces as well`)

5

And where in the API pages are constants like Z_AXIS documented?

6

Nowhere. A long-standing complaint. In addition to global constants, many of the API classes also have undocumented or poorly documented constants.

7

Thomas,

[quote=“tt_su, post:4, topic:17086”]
You might have more luck with using Geom::PolygonMesh. Have you tried that? (Usually much faster than add_faces as well`)[/quote]

First of all, the external applications that I deal with often require a ‘manifold’, but they also require that none of the faces are reversed. Sometimes, users are bringing a model into SU to simply see what’s reversed, as most of the external apps allow one to reverse a face. The fact that I can’t import the model without SU changing the some of the faces’ orientation is problematic.

As to using a mesh, all of the faces have layers and materials, and may have additional meta-data. I’d have to write some rather messy code to determine which face created by the mesh gets what properties assigned to it.

Since most of the models that are imported are less that 1k faces, the speed isn’t an issue. But, I have seen users with models with 8k faces, and that really slows things down.

Thanks,

Greg

8

I did find this by Jim Foltz in 2012