Autodesk: Update the LineStyle proposal from suggestions

[erikaharrison-adsk]

Description of Proposal

It is preferred to use a separate schema for the DashDotLines, because the dash dot patterns can only be applied for the lines. If we directly add style property to the BasisCurves, the style property will be only valid when the type is linear. This constraint is not convenient. We also add a separate rprim for the new primitive. In this proposal, I add a separate section talking about the extents of the DashDotLines, and a section talking about how to handle screen space pattern. At the end of the proposal, two examples are provided.

Link to Rendered Proposal

Supporting Materials

Previous PRs:

• Autodesk: LineStyle Proposal - CurveStyle Removal #47
• Autodesk: LineStyle Proposal - CurveStyle Update #27
• Autodesk: Add LineStyle proposal #20

Contributing

• I agree to and accept the Supplemental Terms.

[jcowles]

Here are a couple comments, mostly just noodling the details.

The bigger question in my mind is still if this schema is needed - I totally understand the utility of it, but it's also yet another schema to support everywhere, in addition to the underlying existing curves...

[jcowles]

I think "screenSpace" should be one word, "screenspace"

[PierreWang]

Yes, you are right.

[jcowles]

This is conditional on the screenspacePattern attribute - it seems when screenspacePattern is false, then the line does have an extent in worldspace, no?

On the other hand, if screenspacePattern should /only/ be considered for rendering, and DashDotLines have no extent, then perhaps it should exclusively be on the shader/material or be a primvar (like start/endCapType, patternScale)?

[PierreWang]

It is not conditional on the screenspacePattern attibute.

"The width of the line will not be considered, because it is screen spaced, that it is implemented via the shader." In this sentence I mean the width is screenspaced. The attribute screenspacePattern only control if the pattern is screenspaced. But no matter whether it is true or false, the width of the line will always be screenspaced.

The default extents for a Curve is the bound box of the control points, and then be expanded with the width of the Curve. But the width for DashDotLines is screen spaced, and it is implemented in the fragment shader, we don't include the width in the extents calculation.

So DashDotLines will always have an extents, which is just the bound box of the control points.

[PierreWang]

The bigger question in my mind is still if this schema is needed - I totally understand the utility of it, but it's also yet another schema to support everywhere, in addition to the underlying existing curves...

As @nvmkuruc pointed, the dash-dot patterned lines will interpret the width as screen-space width. This is different from the definition of a common Curve. To avoid schema slicing, it is better to use a separate typed schema.

[PierreWang]

In the new change, we create a new schema DashDotPattern. The pattern can be set via an array of float2. So we don't need to use a texture to provide the pattern. And we don't require that the DashDotLines primitive must binds a material. Instead, if the DashDotLines primitive has a pattern, it should bind a DashDotPattern.

[spiffmon]

Specifying the Pattern as a separate prim that must be bound via relationship seems like overkill here, and imposes more complexity/cost on the scenegraph and Hydra efficiency than a simpler, API-only solution would. UsdShadeMaterial must be bound because it consists of multiple prims, and because the binding mechanism itself needs to be very "rich" (i.e. complicated).

As an alternative, could we get rid of the DashDotPattern Typed schema, instead putting all of its properties into DashDotPatternAPI? Then, the simple case is very simple: all the information for a single DashDotLines is contained on the prim, very efficiently processed by Hydra. In the mentioned case of wanting to "bind" the same Pattern onto multiple DashDotLines primitives, this seems like a CSS-inspired dream case for the use of class inheritance in USD.

Now we can't build inheritance into the schema itself (composition doesn't consult the UsdSchemaRegistry), but we can provide "strong guidance" in the spec (and helper functions in the schema classes) that DashDotLines primitives should minimally inherit from a "_class_DashDotPattern", and potentially also more specific/granular classes tailored to the asset/scene. So, each of the DashDotLine primitives in the "Diagram1" asset might look something like:

def DashDotLines "TopArc" (
    prepend inherits = [</_class_Diagram1_DD_Pattern>, </_class_DashDotPattern>]
)
{
}

so then anyone referencing that asset could affect all of its DashDotLines (and no others) by putting opinions for DashDotPatternAPI in a spec for </_class_Diagram1_DD_Pattern> .

[PierreWang]

Thank you. I will modify the proposal. And also for the text proposal, I will also merge the TextStyle into TextStyleAPI, and the same for ParagraphStyle and ColumnStyle.

[PierreWang]

Hi @spiffmon , I have updated the proposal. The properties of DashDotPattern is now in DashDotPatternAPI. I don't know if my sample is right:

def DashDotLines "StyledPolyline" (
    inherits = [</Pattern>]
){
    uniform bool screenspacePattern = true
    uniform token startCapType = "triangle"
    uniform token endCapType = "triangle"
    uniform float patternScale = 11
    int[] curveVertexCounts = [3, 4]
    point3f[] points = [(0, 0, 0), (10, 10, 0), (10, 20, 0), (0, 30, 0), (-10, 40, 0), (-10, 50, 0), (0, 60, 0)]
    float[] widths = [10] (interpolation = "constant")
    color3f[] primvars:displayColor = [(0, 0, 1)]
}
def "Pattern" (
    prepend apiSchemas = ["DashDotPatternAPI"]
)
{
    uniform float patternPeriod = 10
    uniform float2[] pattern    = [(0, 5), (2.5, 0)]
}

In practice, I found that I could not read the patternPeriod and pattern property from the "StyledPolyline" prim in the adapter of DashDotLines. I think as I used inheritance, the properties should be available in the prim.

[spiffmon]

Yes, inherits should make the API schema be present on </StyledPolyline>, and you should be able to confirm that in usdview or any python shell. I don't really know what might be the problem in your Hydra adapter, though I know that in Hydra 2 the general pattern would be to have a SI specifically for DashDotPatternAPI... others here might be able to help more, if you can provide a bit more context on the code?

[PierreWang]

Yes, inherits should make the API schema be present on </StyledPolyline>, and you should be able to confirm that in usdview or any python shell. I don't really know what might be the problem in your Hydra adapter, though I know that in Hydra 2 the general pattern would be to have a SI specifically for DashDotPatternAPI... others here might be able to help more, if you can provide a bit more context on the code?

Thank you. I made a further check today and found a bug in my code. There is no problem now.

[PierreWang]

The implementation of this proposal is here:
PixarAnimationStudios/OpenUSD#3151