F. Sebastian (spiff) Grassia

@flord , I was actually shocked that a UsdPrimvarReader_string feeding a UsdUvTexture's `inputs:file` was working for you, as this was not a workflow we wanted to support (complications for GPU...

Hi @ahemberger , renderer-independent support for primvar substitution still does not exist in Hydra, which means you can only use renderer-specific affordances (RenderMan also has its own syntax for primvar...

Hi @ahemberger!    @rafalSFX raised this again this morning in the usd-materialx monthly working group, and I think we are all aligned on where we want to go, which is pretty...

... sorry, there is still potentially a missing piece even for "primvar-substituting renderers", which is that if Hydra is configured to be parsimonious about which primvars it consumes and presents...

Great issue to raise, @flord ! Unless people think it is vitally necessary (and there is no discussion of it in the MaterialX spec), it would be **ideal** for simplicity...

This proposal does seem like a more flexible solution than a special thin_surface shader. From a USD perspective, It, like any change to what a material definition is, implies a...

I like "it can have different materials on each side, if the geometry is double sided" but pedantically would suggest going further, avoiding use of "material" altogether, since Material is...

@proog128 , I thought it was redundant as part of the material definition. Question: is there a meaningful scenario in which we would name a back_surface bsdf but did *not*...

@proog128 , my concern and questioning was for the user-level object model that we would expose in UsdShadeMaterial, and those concerns may indeed be different from those of the code...

I think I follow why it is important for codegen and the underlying math to have an explicit declaration of thin_walled behavior. But I am unsure if it is advantageous...