Light seam

Hello! This is an unwanted seam:


The problem will temporarily disappear if change a random mesh setting but will come back after moving to a different frame.

Blender’s Eevee renders a better result:

I think that’s because of the lighting, it disappears after I turn of the lights:

That could be a discontinuity in the shading normal interpolation.
That would become visible if you visualized the interpolated normals via the Render Settings → Common → Debug View options.
If there is a discontinuity visible in that, then there might be a difference in how the normal attributes are handled inside Blender and inside the exported USD file.

USD usually assumes Catmull-Clark subdivisions on meshes by default and that needs to be explicitly disabled if a mesh is just a “standard” mesh with all vertex attributes provided. Means that seam would happen when the mesh is not closed and using subdivisions. Visualizing it as wireframe would show if the color seam is exactly on primitive edges.

To check for the subdivision scheme you can export the USD scene as USDA to a local folder, open that USDA file in a text editor, look for that mesh, and check if is has a subdivisionScheme token. If not, try adding a line with uniform token subdivisionScheme = "none" inside the resp. UsdGeomMesh scope, save the file and reload it into Create.
If that solves the issue, then the file has not been correctly exported to USD.

Or simply change the settings inside the mesh refinement properties you had in the other screenshot.

Also you can decrease the value of lights “Specular Multiplier” , to solve cheap&dirty way.


Thank you.

This is it in the debug mode:

Using “None” fixes the issue. But my mesh will be unsubdivided, which is unwanted for me.

I used the Blender app provided by Omniverse and used the default settings of the exporter (except turned on animation). Should I report a bug in that category?

Thanks but I prefer to have specularity.

1 Like

Well, if the mesh is supposed to use Catmull-Clark subdivisions and that is behaving differently inside Blender and Omniverse, then it would make sense to get the original Blender model to check if that is supposed to look identical in both renderers.

Are you using a NormalMap?
If you are passing UsdPreviewSurface in the material, the NormalMap may be its seam.
In this case, using OmniPBR in the material and setting the Color Space to “raw” in the NormalMap may solve the problem.

I disabled the subdivision modifier before exporting due to this bug: "Apply Subdiv" always works - #3 by makowalski

But in Blender, it looks fine with Catmull-Clark:

Thanks but it doesn’t solve the problem.