LineStyle schema additions, implementation

[tcauchois]

Hi all,

It looks to me like the LineStyle proposal schema definition is incomplete? It talks about a few requirements:

• Line cap
• Line joint
• Screen-space line width
• Line dot-dash pattern

... but only proposes the "style" attribute for handling line patterns, and doesn't specify any of the inputs to the pattern e.g. what the opacity along the curve parameterization is. I'd love to see this specified and think it could be done so in an abstract way; e.g. as attributes describing styling, rather than shader code. I also think this is potentially a place where an API schema would be pretty compelling; e.g. UsdGeomCurveStyleAPI.

On the implementation end: implementing the mechanisms of stylization as GLSL shaders that replace the bound material breaks some of the abstractions we have around the USD object model. If the stylization is expressed as USD attributes, I think there are a few natural places to add them to (for example) Storm rendering: (1) Storm uses tessellation shaders to support cubic curve drawing. The drawing pipeline for linear curves is much simpler, but we could augment it to handle caps and joints, it seems like. (2) Storm already has some internal hooks for interpreting "width" in units of pixels, and if we have a standard USD way to flag this we could just connect those mechanisms. (3) Storm code-generates a fragment shader main body for lines, which then calls into the material to compute color. If we add a stylization step before we call into the material, we can combine the results of that stylization step (opacity for line patterns/possibly for rounding caps) with the result of material evaluation, letting stylized curves keep using materials. I think that would make for a richer feature.

Thanks! Tom

[PierreWang]

Thank you for your comment.

We are going to update the proposal in a short time. In the update, we will provide a new typed schema DashDotLines for the dash-dot patterned lines. This is because the implementation is quite different from the current BasisCurves.

Our implementation will only support dash-dot pattern for lines (or linear curves in other words). I don't know if anyone plans to support dash-dot for a general curve. Do you think it worths to have a more general schema such as DashDotCurves? Or we keep the DashDotLines schema because it is already enough?

For the patterns, we hope that the line pattern could be set via a pattern file. In our implementation the shader will read in the pattern through the texture, so we save the line pattern in a texture file.

[tcauchois]

If you have an example of the pattern file, or can describe what it's like, that would be great! I'd love to have a better understanding of how that might work. If it's just a repeating pattern applied to the line, all hydra curves are parameterized in u (along the curve) and v (along the width), so in theory you could apply the pattern to a cubic curve, although I don't know if anybody is asking for that.

Matt Kuruc's "VizPrim" proposal (https://github.com/PixarAnimationStudios/OpenUSD-proposals/pull/42) has a lot of overlap with this proposal and the billboards proposal, and in particular talks about whether this kind of stylization (and particularly, usage of screen-space widths) is best implemented as new prim types, API schemas, or new attributes. I think that's a good discussion topic for the community. My personal interest is only that all of these new features share the same hydra implementation (or 99% of one); I want to avoid having a second usdImaging curves adapter or hdSt curves prim, if I can accommodate LineStyle with just a few new hydra inputs.

[PierreWang]

usage of screen-space widths) is best implemented as new prim types, API schemas, or new attributes. I think that's a good discussion topic for the community. My personal interest is only that all of these new features share the same hydra implementation (or 99% of one); I want to avoid having a second usdImaging curves adapter or hdSt curves prim, if I can accommodate LineStyle with just a few new hydra inputs.

I am afraid we have to have different adapter and even rprims. The implementation is quite different. More code is needed in the fragment shader. I also expect more discussion on the VizPrim proposal. And I hope that we can have a presence shader which is for handling fragment opacity. Many VizPrims require this shader.

[tcauchois]

Once the schema side is more locked down, I'd like to engage on this a bit more, because I think we could implement everything in this proposal in hdSt basis curves if we add a few more controls to the hydra representation. Storm prims have a "geometric shader" which is shadercode that isn't related to the material, but which helps get the correct shape, and those shaders can have their own resources. Whether to expand the API for basis curves or create a new prim is mostly a question of how divergent the final graphics pipeline will look for those prims. If we do create new prims (for example, I think having Text prims and not just using Mesh prims as cards is warranted), I want to put some thought into sharing as much code as possible between the mesh and text prims.

I forget if you all submitted a code PR for linestyle as well, but I can try to comment on your code PRs with my ideas.

[PierreWang]

Hi @tcauchois , the updated proposal is here #60 . I haven't submit a code PR.