Orienting faces consistently with the SDK

Thanks @DanRathbun .

There is another question. SKP SDK provides the API to fix the inconsistent face orientation issue for component and model. Why is there no API to fix the inconsistent face orientation issue on group?

A group is just a “special” class of component instance (whose definition is hidden from the Component Browser panel, and when there are more than 1 instance manually opening the instance for edit creates a new unique clone definition for the instance being edited.)

So groups, component instances and images all are instances of a “mother” definition.

The solution with the C API is like that given above. When you need functionality from related classes of objects you will need to cast your object to that other class. (So cast your SUGroupRef to an SUComponentInstanceRef and then call the desired function.)

From the API comments:
SUComponentDefinitionOrientFacesConsistently() is available since SKP 2016 and API 4.0.
SUModelOrientFacesConsistently() is available since SKP 2018 and API 6.0.

Two questions:

  1. will model created in older SKP applications (say SKP 2015) fail these two functions?
  2. SUModelOrientFacesConsistently() fixes the orientation to be consistently in the file. Is it still necessary to call SUComponentDefinitionOrientFacesConsistently() for each component?

SUModelOrientFacesConsistently() fixes the orientation if the reversed face number is small. However, it will reverse the correct face if majority faces are reversed before.
For example, I reversed 5 faces of a cube, which has 6 faces.
This API will reverse the left 1 face to keep they have the same consistence.
This is not I expect.
Is it as designed?
Is there an option to fix the 5 faces in above cube example?

I believe so.

Consistent != Correct

Hi @DanRathbun,

In @zhangping1231 test case, when the front face of six faces for a cube group point to internal, when calling SUComponentInstanceComputeVolume() to check if it is a manifold and the return result is a manifold. Is it expected?

Another question is
After calling fixing orientation faces, the mesh qualities could be either worse or better, right? From SKP experts’ perspective, do you suggest to use SUModelOrientFacesConsistently() in our common workflow?

The orientation of the an instance object’s face normals should not have any bearing on whether or not the geometry forms a “watertight” 3D region.

If you need proof, create test cases yourself, and then test.

I have no idea. The question is much too general. The use cases are far too many to contemplate.

The documentation for the SUModelOrientFacesConsistently() function indicates that if the 2nd parameter is true, that the orientation will be applied to component definitions as well.

And again, a coder should create test cases, and test to reassure themself.

I do not know what your “common workflow” is. And I am not inclined to even attempt a guess.
I think that you should be intelligent enough to determine your own best course of action.

Attached file is a cube group. In the cube group, there is a cube geometry. After calling SUModelOrientFacesConsistently() and then check if the group is a solid group. The returned result is a solid group. However, the orientation of the instance object’s face normals pointer to the inner of body. Is it right?cube.skp (102.0 KB)

In addition, how to get the orientation of the instance face’s normal?

After calling the SUModelOrientFacesConsistently() with the 2nd parameter “true” to fixes the orientation to be consistently in the file, there are some customer models with bad qualities, see the snapshot

So when reading a skp file, I am thinking the function SUModelOrientFacesConsistently() should be always called or not?

It could be correct. For example the cube might be the internal hollow surfaces of some much larger 3D solid. So in this example, it would be correct for the normal of the faces to point inward.

I think the real question you want to ask is, … is the API functions smart enough to know which way the face normals should point. The answer is NO. The function is “non-intelligent”.

@thomthom or @bugra , it looks as though the soften and/or smooth properties are getting reset. Is this a bug?

@DanRathbun @thomthom and @bugra Do you have any inputs?

You might file an issue in the bug tracker …