MaterialXGenMari? about materialx HOT 9 CLOSED

Hi Mitch,

That's a great question. I have very limited knowledge about Mari's shading system, but for the question about a MaterialXGenMari library the answer is yes this would definitely be possible, it would be the appropriate solution to derive a custom code generator targeting Mari. This is how the MaterialX shadergen system is designed to work, where you can inherit from existing generator classes (when possible) and customize for new targets.

MaterialXGenGlsl is generating vertex/pixel shader pairs for a quite simple forward renderer, mainly targeting the MaterialXView application. But it would be a good start to derive from, and depending on how different this is from Mari's render pipeline you can override and customize smaller or larger parts of this.

For example, in Maya the viewport is similar in the sense that GLSL code fragments are stitched together using an XML based fragment system. For this we have derived generator classes targeting Maya by inheriting from classes in MaterialXGenGlsl. Code for this library can be found in our fork: https://github.com/autodesk-forks/MaterialX/tree/adsk_contrib/dev/source/MaterialXGenOgsXml

I hope others can share more details on Mari's shading system and maybe how/if they have used MaterialX codegen already targeting Mari in some form.

from materialx.

The latest USD change log from Pixar hints there are initial support for MaterialX in hdStorm in the upcoming 21.05 release:
PixarAnimationStudios/OpenUSD@f57e281

This might be another good source of inspiration for how to integrate MaterialX codegen to another viewport renderer. I don't know the details yet but I think this is based on MaterialXGenGlsl as well.

from materialx.

Okay, thanks for the response Niklas!

I'll take a look around the MaterialXGenGlsl code and your Maya viewport fork to see what they're all about. I've written a fair amount of custom shader code for Mari, so this should give me a rough idea of what's involved and how much to expect out of a possible MaterialXGenMari.

mitch

from materialx.

@mprater Good question, and I agree with the notes from @niklasharrysson above. Pixar's integration of MaterialX code generation into Hydra/Storm is definitely a good example to look at, and here's the declaration of the HdStMaterialXShaderGen class which specializes MaterialX::GlslShaderGenerator for Hydra/Storm:

https://github.com/PixarAnimationStudios/USD/blob/d289c4c52f88870822205223b626b94be14c78d6/pxr/imaging/hdSt/materialXShaderGen.h#L37

I know that Karen Lucknavalai at Pixar has plans for this system in the future, and it could be worthwhile to bring her into the conversation once you have an initial framework. On the MaterialX side, I believe we can also do a more thorough job of providing virtual methods for ShaderGenerator subclasses to override, and we're open to ideas and contributions in this area.

from materialx.

Hi Jonathan! I think the biggest issue here will be the shading limitations imposed by Mari. Rather than being a (relatively simple) glsl rendering system, it imposes a great deal of structure onto the shading components in order to operate as a paint system. As such, it uses individual shading nodes whose purposes fall into a very small number of functional categories corresponding to paint layer manipulation, and Mari assembles the shading network into its final OpenGL form to be used in the viewport. From what I've gathered so far about the MaterialXShaderGen process, this shading framework doesn't align very well. Is it possible to use (or modify) the MateralXShaderGen process to generate partial shaders (shader functions essentially), that use a narrowly defined API?

from materialx.

Hold on - now that I've thought about it, instead of trying to impose Mari's shading framework on MaterialX, I should turn that around. Mari has a custom shader category called a "standalone" shader, which is essentially what MaterialX generates as I understand it. Yes... I think this could work. I'll take a closer look at how the vertex and fragment shaders are generated by MaterialX - Mari has a fixed vertex shader and its own set of semantic interfaces, but it seems like those should be surmountable.

from materialx.

@mprater One interesting use case for this technology would be the ability to render MaterialX shading models directly in Mari, converting the underlying MaterialX Physically Based Shading graph into Mari GLSL/XML on demand. Shading models such as Autodesk Standard Surface and UsdPreviewSurface, which have public MaterialX definitions, would be supported automatically in Mari. And studios with their own custom shading models could simply provide MaterialX PBS graphs to Mari to enable their use in painting workflows.

from materialx.

Yes, it's definitely worth pursuing. Unfortunately, it's not anywhere near the top of my to-do list right now.

from materialx.

No problem at all, @mprater, and I'll close this issue for now. Feel free to reopen it in the future, if either your team or the Mari team at Foundry end up taking on this project, and we're happy to provide guidance.

from materialx.