AcademySoftwareFoundation / MaterialX

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers.
http://www.materialx.org/
Apache License 2.0
1.82k stars 332 forks source link

Adaptive Parameterization Bsdf Implementation #649

Closed mprater closed 2 years ago

mprater commented 3 years ago

Hi All,

This is more of an inquiry than an issue. I'm wondering if anyone is actively working on a MaterialX bsdf implementation of the Dupuy/Jakob Adaptive Material Parameterization. There are ILM-supplied materials in their database, so it seems reasonable that such an implementation may exist or is in progress.

Thanks, mitch

jstone-lucasfilm commented 3 years ago

That's an idea that we've discussed internally at ILM, and I think it's a really compelling proposal for a MaterialX feature, but we haven't started development work on this functionality ourselves. If your team would be interested in working on this feature, we'd definitely be open to supporting that work and ultimately merging the feature into MaterialX.

mprater commented 3 years ago

Okay, good to know Jonathan. We have been working with Wenzel for a while now on some unique materials used in our productions, but I haven't (yet) had the time to implement the bsdf.

I'll start digging through the EPFL resources again to re-familiarize myself (it's been a couple years), and report back here with a development outline.

mprater commented 3 years ago

Okay, it looks like the simplest/most expedient path toward an initial implementation will be to do this in PRMan/RIS (which is ultimately where we need it anyway), since the available source is in c++ and it conforms well to the integration system used by PRMan. Once that's done, we can take a look at how to propagate that into Lama (via Pixar?), and from there into MaterialX.

mprater commented 3 years ago

In particular, a MaterialX implementation will hinge on converting the material .bsdf data files and their render-time acquisition/processing into the texture map/cache domain of whatever rendering systems MaterialX supports.

jstone-lucasfilm commented 3 years ago

For MaterialX, making a new BSDF available for rendering would mean making it available in the shading languages that MaterialX supports via code generation (OSL, GLSL, and MDL). Support for RenderMan C++ seems like a logical first step for your team, and let us know if you run into production cases where generalization to open shading languages such as these would be valuable as well.

mprater commented 3 years ago

Right... so how does the process normally go: a new shading language capability first and then a MaterialX definition, or vice versa?

OSL (I don't know MDL at all) could be expanded with a new Material Closure. Glsl seems like somewhat of a special case though, since it is its own implementation. It's the glsl case in particular that made me think the material.bsdf files would have to be converted into textures so the glsl implementation could access the data.

jstone-lucasfilm commented 3 years ago

This is a good question, and I can give you a sense of how we've proceeded with the implementation of other novel BSDFs in the past.

As one concrete example, we've gone through the process of implementing a prototype for the reparameterized Lazanyi-Schlick model, which is being considered as a potential MaterialX node one day. For initial validation, we first implemented this in our production shading environment, allowing us to leverage all of our custom tools. Then for validation in an open environment, we implemented the shading model in GLSL, allowing us to evaluate its behavior in real-time tools such as MaterialXView. To take this the extra step of making it a MaterialX feature, we'll then need to present it in a context such as the MaterialX TSC, verifying that the developers of OSL, MDL, and other rendering environments support its inclusion in the standard.

For your example of the Dupuy/Jakob acquired BSDF, I think it makes sense to start with the production environment you're most familiar with (e.g. RenderMan C++). For the next step of a first open environment, you might consider OSL, since it's straightforward to write new closures and validate them in open tools such as testrender. As you've noted, there would be some additional research required to get the Dupuy/Jakob model up and running in GLSL, where the BSDF data would likely be stored as a combination of texture look-up tables and shader uniforms. Additionally, you'd want to consider what the ideal interface for this shading model would look like in MaterialX, since it would be the first example of a BSDF defined by acquired data on disk, rather than a set of artist-tunable parameters.

mprater commented 3 years ago

Ah! Good - yes that all makes perfect sense - thanks for the explanation!

Clearly our first step is a PRMan/RIS implementation; and once that's done, we can circle back and decide where to go from there.

jstone-lucasfilm commented 2 years ago

I'll close out this issue for now, @mprater, and I wanted to note that the MaterialX channel of the ASWF Slack is now the ideal place for this type of discussion of new ideas for MaterialX. Feel free to join us there!

https://www.materialx.org/DiscForum.html