Text Hydra-level feedback

[tcauchois]

Hi all,

Some feedback on the implementation portion of the text proposal:

Rprims and Shader:

• I like the idea of carrying the text type all the way to Storm prim types. At one point I was wondering if a scene index could convert the UsdImaging text prims into plain meshes and basis curves, but I buy the argument that text might want different draw pipelines. As much as possible, I'd like to reuse existing Storm backend functionality, though; so for example, the text can create a repr with (e.g.) a mesh draw item for rasterized text and a curve draw item for strikethrough. We can define some text-specific geometric shader mixins but hopefully they would be minimal.
• Since the layout is presumably happening on the CPU as a preprocess, it would be really nice to only support one text prim in Storm. You could imagine the layout step happening in a scene index, and the Storm text prim being a list of glyph, position.
• The presence shader/getOpacity is a great way to deal with figuring out which fragments are part of a glyph, but it shouldn't be part of public API. I'd expect that when you are constructing the text geometric shader, you're mixing in some shader code that e.g. might determine whether a fragment is part of the glyph or the background, and that lives in hdSt/shaders. Any USD-level material binding (if allowed, but I think it would be neat!) would define surfaceShader as usual, but the text fragment shader could decide whether to call surfaceShader based on the presence shader, or maybe modulate the surfaceShader by the presence shader or something.
• If one of our rendering methods is glyph maps, it would be fantastic to find a way to cache and share the glyph map. As one idea: you could insert a hydra texture prim at the location of the RenderStyle prim and fill it with a glyph map for that style, and any text sharing the same style could refer to that glyph map. Or else the scene index/hdSt prim responsible for generating the glyph map could just make sure there was a registry of them on the resource registry, or something.

UsdImagingText, UsdImagingMarkupParser:

• These seem best handled in an HdSceneIndex plugin; this is a much cleaner way to add proceduralism than UsdImaging adapters. So I might define these plugins in pxr/imaging/hdText, the implementations in pxr/imaging/plugin/foo.

UsdImagingTextRenderer:

• I'd very much like text rendering to follow the current storm pattern of HdStDrawItem/HdStGeometricShader/HdStBufferArrayRange plus optional bound material. I might need to look at the PR to evaluate this part, but I'm nervous about having a plugin renderer. Does the renderer just return shader code? If so, can that shader code live in hdSt/shaders/? If we have multiple text implementations, we can have multiple snippets in a glslfx that the HdSt text prim can choose between. If there are any HdSt-level API issues that make it hard to add new types of draw item, we can definitely collaborate on them to come up with a nice solution.

Thanks!
Tom

[PierreWang]

Thank you. There are several discussions about the rendering part of the text. One issue is that currently there are several different ways to render the characters. MSDF is one of the most commonly used method, but some people may still choose to draw the characters using a simple bitmap. I hope that we can have a default way to draw the characters, but user could use their own method. So I would like to have the getOpacity function implemented by a plugin. We can provide a default plugin but the user could choose their own implementation.

I hope that there could be a separate presence shader part for the whole material network. Currently there is only the surface shader. Not only the text primitive, but the line style and other 2D like primitive may benefit from the shader.