Hi MDL developers,
first of all, thanks for your work and for finally making the SDK publicly available! Looks like the MDL really got it all right and could solve many of the interoperability issues that exist with heterogeneous tool pipelines and PBR today.
The SDK is quite impressive too (nice lean ABI layer, BTW), and I’m currently reading into the docs / trying to get on top of things, so I hope you don’t mind my (at this point possibly naive) questions.
It seems the following recipe would suffice to get some basic rendering and running (only considering the surface BSDF for simplicity of discussion):
- Implement the BSDFs that I want my renderer to use for MDL materials as functions that return 'color' in some kind of built-ins module (OSL seems complete enough to express those)
- Write some code that traverses the material's 'surface.scattering' expression and replaces all BSDFs found with those functions
- Pin the expression onto some dummy material's dummy BSDF's 'tint' parameter, to generate a single entry point that accepts 'state'
Yet API-wise the whole thing feels somewhat off-beat, but it also seems needlessly complex to write code against several (in case of supporting CUDA / GLSL) additional APIs for compilation, where I already have compilation abstracted by the MDL SDK…
- The hack sketched out above would work, right?
- Is there a nicer way (there's a 'LinkUnit' and designated built-in modules that support 'native' annotations which hint into that direction, but little detail)?
- Is there some way to lock parameters to constants in class compilation mode / or, alternatively a way to mark inputs as varying (even if they default to a constant) for instance-level compilation?