Assertion in subdivision surface

[Gary_B_]

I'm still trying to narrow this down to specific geometry, but in v2.6.1 I have geometry from a user that's triggering an assertion in catmullclark_coefficients.h

    __forceinline float limittangent_a(const size_t i, const size_t n)
    {
      assert(n < MAX_RING_FACE_VALENCE);
      assert(i < n);
      return table_limittangent_a;
    }

where MAX_RING_FACE_VALENCE is 32 and n is also 32 at runtime. This is fairly well nested within the build process for the bvh tree, and it's been difficult to see whether this geometry is violating some contract with the Embree api that I'm not aware of.

Is there a way to query whether subdivision surface cage geometry satisfies the requirements of Embree? I have a fallback I've been using for geometry with ngons > 4 sides that submits the already subdivided quads and triangles to Embree, but I'm in danger of going to my fallback for way too much geometry. I definitely want to submit more, not fewer, subdivision surfaces directly.

Any insights?

P.S. I've attached a stack crawl of the assertion when hit, just in case it's useful.

[SvenW_Intel]

Yes there are limits of the maximal 16 vertices for a face and the maximal number of neighboring faces of a vertex is 32. These constants can be configured in kernels/common/catmullclark_coefficients.h. Normally Embree should just ignore faces with too high valences, looks like there is a bug and this face got to the backend.

Can you describe which geometry causes the issue? Is it a large quad-fan?

Sven

[Gary_B_]

I've isolated the model for this subdivision surface that's causing the assertion to be hit.  It's attached as a zip containing multiple file formats.  The Strata Design 3D variant is the model file with an actual subdivision surface in-program, while the other versions are the surface cage exported as a mesh.

You'll see that the designer is trying to create a tube with inner and outer walls, but they haven't really defined a closed volume.

[SvenW_Intel]

Thanks for sharing that model. I fixed the assertion issue and then realized that the root cause of the issue is the geometry. The winding order of the outer torus has to be flipped. Only then the entire surface has the same winding order for each patch. We have to discuss how to handle such cases properly in the next release.