Adding MDL material support - feedbacks requested

Contributing to Blender
1

Background
Nvidia’s MDL is a shading language that describes material’s behaviour against light rays.
It is quite popular among certain user base which depends on Iray renderer (since Iray uses MDL).
e.g. Daz Studio users
After having discussed with Daz users in online forums, they showed enthusiastic interest in the potential ability to render MDL materials in Blender Cycles.

Since then, I have been researching for a month now on how to make code changes to Cycles in order to render MDL materials that look very close or idential to Iray renders using equivalent MDL materials.
This topic is to discuss what would be the best way to make this code change to Cycles.

Proposed change

  • Add a custom Material Node that represents MDL material.
    The node will work like how OSL script node works currently.
    Following is a screenshot that shows proposed MDL script node with MDL file path and function parameters:
    https://cdn.discordapp.com/attachments/658493790666883073/658493809063100456/unknown.png

  • Code change to the following sections in Cycles codebase.
    The following changes will have to be made within Cycles:

    • BSDF evaluation code
    • BSDF sampling code

  • A custom open sourced Blender build. It is unclear at this point whether it’s possible to gracefully integrate MDL support without tempering with Cycles’ intended functionalities. Therefore, code changes will be released as a custom Blender build for the time being.

  • Device support:
    This change will rely on MDL SDK to compile the MDL script into executable shader bytecodes. Currently, MDL SDK only supports the following backends:

    • CUDA
    • CPU (LLVM-IR or x86_64)
    • HLSL
    • GLSL (experimental)

    Therefore, MDL support in Cycles will be limited to following device backends:

    • CUDA
    • Optix
    • CPU

Notes
To make it easier to communicate and collaborate ideas, I created a public page that documents my planned technical design for MDL support.
This page will contain technical details such as exactly what function within Cycles will be changed, etc.
https://www.notion.so/nprlab/MDL-Integration-to-Blender-Cycles-65a8e0523c59410caa8db9dd919980df

1 Like
2

I would rather focus on improving our built-in BSDFs to add some functionality that is available in MDL, and see work done for better material I/O. We still can do so much better in those areas, that investing time in MDL seems like the wrong priority right now.

The important use case is also a bit unclear to me. If MDL becomes more of an interchange standard it could make sense to bet on this, but it’s not clear that is happening. And in that case I would expect the emphasis would be more on authoring MDL materials and exporting, since that’s where Blender typically fits in the pipeline. And that has implications for the user interface, a script node is not very user friendly for authoring.

MDL does not work on all devices which immediately makes it something that few users will rely on. Such materials can’t be shared as easily so similar to OSL it might not get much attention in tutorials and material libraries because of that.

So at the moment I’m not convinced that the code complexity and maintenance cost will be worth it and I would likely reject a patch for MDL. It would slow us down too much when we want to make more important changes, as happened with OSL.

1 Like
3

I understand.

I didn’t expect this change to be accepted to the main branch. and at least thanks to your input, there’s a clear reason why it won’t be.

I guess I should make the end goal more clear.

The End Goal

  • A custom Cycles engine that’s accessed via one of the followings:
    • Custom Blender build
    • Blender addon to standard blender
    • Plugin to Daz Studio software
  • Tailored for Daz users, not regular Blender users. They mostly don’t care about authoring materials or creating 3d models from scratch.
  • Non-photorealistic rendering features added on top of MDL support

Given the use case I stated, would like to get feedbacks on whether the proposal is a good technical decision.

If this forum is for only talking about planned changes for main Blender release, I will discontinue this topic

4

Just a side note, the reason why we don’t pay too much attention to OSL in tutorials is that it just works with CPU, as soon as it’s working in GPU too I assure you that we will use it extensively! But right now using OSL is limiting ourselves to CPU rendering, something we rather prefer to avoid :slight_smile:

About MDL I agree with you, as an extreme situation I would rather prefer to have an option in the principled shader that enables the MDL shading mode, but it works as transparent as possible to the user, that way a fallback to normal principled would be easy for OpenCL users, but I agree that features should have to be added in general both for MDL and normal shading, at least for principled

5

For what it’s worth, to me it seems that Material-X seems will be the emerging standard. We’ve been testing Houdini 18 with its USD based workflow and Materal-X is the main (external) format for material interchange that it supports. It’s also supported by Clarisse which is also working on USD. Arnold and Renderman support it, Not to mention, Pixar is working to integrate material-X into USD natively. So, I’m expecting the future to be USD and Material-X. Another cool thing is that Material-X is based on a node graph so it might be easier to translate directly into and from Cycles/Eevee graphs.

3 Likes