Text proposal default material

[meshula]

@PierreWang wrote in https://github.com/PixarAnimationStudios/OpenUSD-proposals/pull/48

Q: Why we need material binding for text? A: The rendering of a character is something to get the opacity of each pixel. Different rendering technique may have different way to generate the opacity. So we use material binding to allow the user to give custom shader for the getOpacity function.

@meshula wrote

material binding: It seems a bit confusing to merely say that one should bind a material in order to see something rendered. This makes sense, but any of the default materials like PreviewSurface are inappropriate in that they are all about previewing surfaces. One can imagine that people will on day one want materials that implements "closest" sampling for bitmap style fonts; a filtered sampler for typical font atlas purposes, and an SDF based shader for fancy rendering. My intuition is that we should provide either one Uber-text material, or three specialized ones. To avoid branching, I lean to three.

[tcauchois]

I'd like to advocate for a distinction between material (i.e. rasterizer shader program) and material (i.e. "surfaceShader" definition with pattern and bxdf information). Much as with LineStyle, the part of the shader program that concerns text is basically a presence shader: identify to the renderer that these fragments will be written to the framebuffer to construct a glyph. BXDF shading, like what UsdPreviewSurface does, is orthogonal.

I don't think we should be using Usd material functionality to define presence shaders; I think that should be a render delegate implementation detail, which can be selected based on text rendering method, and which is separate from the concept of bxdf shading. In Storm terms, we can build a pipeline to draw text as either curves or billboards, calculate the presence in the fragment shader, and any subsequent invocation of surfaceShader() is irrelevant to the feature.

Again in Storm terms, I'd advocate for a different pipeline/codegen snippet for each rendering method, although parametrized enough to batch text rendering with the same method and different contents.

[PierreWang]

Yes, I totally agree that we need a presence shader. Currently there are geometric shader and surface shader. We also need to be able to set presence shader to the program. I don't put it into the text proposal because it is not only for the text. And our LineStyle proposal will also benefit from the presence shader. Is there any proposal related with presence shader?

[PierreWang]

@meshula Indeed we use the TextRenderer plugin to allow for different rendering methods. For example, there can be two TextRenderer plugins. One will use font atlas and another is an SDF based renderer. You can specify what renderer you want via the name of the renderer.

Well, I think one problem with my proposal is that it lacks examples. I need to add some examples in the next update.