Add per-prim depth bias

[xum-adsk]

Description of Change(s)

This change is a proposal for issue #1548

The depth bias is useful to address z-fighting between 2 overlapping
gprims. A common example is mesh decal. In a CAD sketch, there can be
a lot of co-planar and overlapping objects.

The depth bias is specified in different ways in different renderers.

Unity exposes 2 glPolygonOffset parameters in shader.
https://docs.unity3d.com/2021.2/Documentation/Manual/SL-Offset.html

Unreal allows to add a world offset towards camera.
https://docs.unrealengine.com/4.26/en-US/WorkingWithContent/MeshDecals/

USD allows to set the glPolygonOffset parameters in a render pass. It
could be more flexible to specify a bias for each prim.

Just like displayColor and displayOpacity, propose to add a new builtin
primvar "primvars:depthPriority". The value is not real bias so the
name is "priority" instead of "bias".

e.g.
A gprim with primvars:depthPriority=[1] will win the same gprim with
primvars:depthPriority=[0] in depth test in GL renderer.

The depth priority is passed to renderer in the same way as other builtin
primvars. Then, Storm biases the vertex toward the camera. Similar to
the "units" parameter in glPolygonOffset function. The bias is small and
only meaningful for perfectly overlapping gprims.

Fixes Issue(s)

• Allow to use mesh decals
• Avoid z-fighting of overlapping co-planar objects.

[jilliene]

Filed as internal issue #USD-6830

[spiffmon]

Thank you, @xum-adsk . We are still gathering our thoughts on how to guide you, here, but one thing that might help is if you can explain in more detail the expected situations (and intentions of the process and data) arising from CAD sketches? Is there any similarity to Blender's "grease pencil drawings" , or is it a more general modeling pattern that needs to be handled more gracefully?

Cheers,
@spiffmon

[xum-adsk]

Thank you @spiffmon . This is expected to address the z-fighting artifacts caused by overlapping meshes. It's a little different from grease pencil, the sketch consists of meshes.

Mesh decals. A decal mesh is a textured subset of the mesh. The mesh and the decal mesh overlap each other so we need a mechanism to pull the decal mesh towards the eye.

Sketch. All geometries are co-planar. In this case, there are z-fighting between the black arrow and gray profile.

[spiffmon]

Thank you, @xum-adsk . I understand the mesh decal problem. The questions I have about the cad sketch are:

1. In the authoring application, is there awareness that it is a sketch consisting of a set of geometries that have a mutual display ordering, or is it just unrelated geometries?
2. Whether it is curves we are talking about or planar meshes, I mentioned the Blender feature because Blender does aggregate the strokes into a “sketch” with a known display ordering between the elements. If this is the same for the CAD sketches, then I think there is somethng we can profitably sink our teeth into, here.

[xum-adsk]

The application is aware of a sketch. It's the parent of the geometries. And the sketch knows the ordering of the geometries within it. But we have some exceptions. If a user is editing the sketch, there are temporary geometries, e.g. dimensions to indicate the length/angle of lines, or radius of a circle). These temporary geometries are not part of the sketch. But they are co-planar with the sketch and should pull towards camera so they draw on top of the sketch.

Both curves and planar meshes. In the above case, black curve > black arrow > gray profile. The curve/arrow/profile all belong to a sketch. The ordering is known.

This is from the application. The blue line belongs to a sketch. The gray arc/line with arrows are temporary objects. They don't have parent-child relationship with the sketch in the application.

[spiffmon]

That's great, @xum-adsk, and provides more confidence for the following suggestions.

Firstly, with regards to the current PR as-is, we generally try not to canonize in the core properties or behaviors that are specific to a particular renderer or class of renderers, and we don't think that the depth bias, as specced, would be useful for path-tracers.

But more importantly, you have called attention to two constructs (mesh decals and 2D, layered drawings) that seem ripe for describing in USD for interchange. Mesh decals are supported in at least three packages. I am unsure exactly how similar or feature-overlapping Blender's grease pencil tool is with CAD sketches, but they surely share the same basic property of using 2D projections of 3D primitives (I state it that way as a challenge to see if it could safely be formulated that way to leverage USD's existing 3D primitives, rather than encoded in terms of 2D primitives) that are ordered to create a layered drawing.

A depth bias, even if sufficient for some renderers to draw these constructs successfully, would not allow them to interchange, or even round-trip, since the semantics is not represented.

So I think what we'd encourage is to figure out how to encode these concepts as USD schemas (which may involve discussions with interested parties from other toolmakers), along with usdImaging adapters, and rendering for at least Storm.

That may be more than you were planning on biting off here, but it also has a much bigger payoff.

[halletj]

Thanks @spiffmon we are reviewing our options internally, and will get back to you asap.