Question about MDL wrapper

Gaming and Visualization Technologies Visualization MDL SDK
21

Is there an internal pooling in MDL, which detects such duplicates? I did not find anything about that in the documentation.

The libbsdf implementations has a mechanism to handle “common subexpressions”. For simple cases like using the same texture for 2 bsdf parameters it will kick in. It will heuristically decide though whether executing code twice or storing and reusing the value is better. There is a fixed ammount of memory reserved for storing results of such expressions, if it runs out of memory expressions might be evaluated multiple times.

22

Thank you very much for the information.

23

OK, but is there a way to access volume-related data through the MDL SDK ?

I finally was able to integrate a MDL material (of the MDL Sphere sample of OptiX 5.1.0) into the Renderer presented in the OptiX Advanced Samples (optixIntro_10) using the MDL SDK 2018 with Compiled_material_traverser_base+Compiled_material_traverser_print
for checking semantics; so that all yet unsupported semantics simply reject the material in my app.

But how to detect “cutout_opacity” from “material_geometry”? I did not find a “CUTOUT” semantics value for it. And how to get “absorption_coefficient” and “scattering_coefficient” from “material_volume” through MDL SDK?

24

To get properties of the volume or the geometry, you can navigate through the expression graph of the compiled material.

Here are two examples:

mi::base::Handle<const mi::neuraylib::IExpression_direct_call> body(compiled_material->get_body());
mi::base::Handle<const mi::neuraylib::IExpression_list> body_args(body->get_arguments());
 
mi::base::Handle<const mi::neuraylib::IExpression_direct_call> geom_constructor(body_args->get_expression<const mi::neuraylib::IExpression_direct_call>("geometry"));
if (geom_constructor)
{
    mi::base::Handle<const mi::neuraylib::IExpression_list> geom_constructor_args(geom_constructor->get_arguments());
    mi::base::Handle<const mi::neuraylib::IExpression> cutout_opacity(geom_constructor_args->get_expression("cutout_opacity"));
}
 
mi::base::Handle<const mi::neuraylib::IExpression_direct_call> volume_constructor(body_args->get_expression<const mi::neuraylib::IExpression_direct_call>("volume"));
if (volume_constructor)
{
    mi::base::Handle<const mi::neuraylib::IExpression_list> volume_constructor_args(volume_constructor->get_arguments());
    mi::base::Handle<const mi::neuraylib::IExpression> absorption_coefficient(volume_constructor_args->get_expression("absorption_coefficient"));
}

depending on your material, the resulting expression can point to another function call or to a constant.
In case of the latter, you can cast it and retrieve the value similar to traverser_base/traverser_print:

mi::base::Handle<const mi::neuraylib::IExpression_constant> cutout_opacity_constant(cutout_opacity->get_interface<const mi::neuraylib::IExpression_constant>());
if (cutout_opacity_constant)
{
    mi::base::Handle<const mi::neuraylib::IValue> value(cutout_opacity_constant->get_value());
    /* ... */
}
25

Thank you very much for this example.

26

in the MDLSphere (OptiX 5.1.0 ) demo architecture: is there a way to obtain the albedo color result from an image texture compiled within a MDL material at run-time in the calling .cu file? I need it for the OptiX AI-based denoiser albedo input buffer.
Otherwise I would always need to load the texture twice (one time in the MDL material and one time in the .cu file)

and in case of the mi::neuraylib::BSDF_EVENT_GLOSSY event: is that set based on a threshold (corresponding to the roughness)?

27

It is not possible to get access to the texture data read within the generated code. While the data could end up unmodified somewhere in the state texture results buffer for some materials, it is not guaranteed and not documented.

If you just don’t want to load the same texture twice into GPU memory, you could adapt the Mdl_helper::compile_df() function to not only return the programs, but also the buffer of texture samplers created in Mdl_helper::create_programs().

In the future, the generated code could also optionally calculate the albedo directly, so for example any scaling of textures and the combination of multiple textures would be handled correctly automatically. We will discuss this internally.

The BSDF_EVENT_GLOSSY event only depends on the involved BSDFs.
Currently these BSDFs result in glossy events:

  • backscattering_glossy_reflection_bsdf
  • microfacet_beckmann_smith_bsdf
  • microfacet_beckmann_vcavities_bsdf
  • microfacet_ggx_smith_bsdf
  • microfacet_ggx_vcavities_bsdf
  • simple_glossy_bsdf
  • ward_geisler_moroder_bsdf

You will get an BSDF_EVENT_ABSORB event in case of absorption, though.
For mixing distribution functions, the events depend on the BSDF chosen for sampling.

28

I successfully now use MDL SDK 2018.1.1 (307800.2890 15 Sep 2018) with OptiX 5.1.1
The only thing I had to change was renaming “nv_freeimage.dll” into “nvmdl_freeimage.dll” (so I simply can use the mdl_helper.cpp unchanged)
And this time anything works fine. Great!

From [url]https://github.com/NVIDIA/MDL-SDK/blob/master/CHANGELOG.md[/url] I found that df::diffuse_edf() is implemented now. But on [url]https://github.com/NVIDIA/MDL-SDK/blob/4e688e04df2de29e32cdb458bb2df1b21edd8628/src/mdl/jit/generator_jit/generator_jit_llvm_df.cpp#L1212[/url]
the line “Unsupported: DS_INTRINSIC_DF_DIFFUSE_EDF” So obviously a typo, right?
The function implementation I found here:
[url]https://github.com/NVIDIA/MDL-SDK/blob/4e688e04df2de29e32cdb458bb2df1b21edd8628/src/mdl/jit/libbsdf/libbsdf.cpp#L3360[/url]

29

I’m glad to here, you had a pretty smooth update experience!

Yes, m1, this is indeed just a typo. It will be fixed in the next version.

30

in “Announcement: MDL SDK 2018.1.1 released” https://devtalk.nvidia.com/default/topic/1042632/mdl-sdk/announcement-mdl-sdk-2018-1-1-released/ :
[…]Support for passing custom texture access functions has been added to the Native backend. The builtin
texture handler can be disabled via the new backend option “use builtin resource handler”.[…]

So within the MDL material a custom texture access is now possible.
Are there any news about the albedo issue for the denoiser?

And on https://developer.nvidia.com/mdl-sdk I found:
[…]MDL editing. Create instances of functions and materials and connect them to create new materials with new interface[…]
And:
[…]The SDK contains components for loading, inspecting, and editing of material definitions […] https://github.com/NVIDIA/MDL-SDK/tree/4c0be9b88ab855526fcba954cf021a490d6899ee
which tool is this in the SDK? I found mdlm,mdlc and i18n, does “MDL editing” refer to one of these?

31

Hi M1,

separate albedo output is not finished yet.

which tool is this in the SDK? I found mdlm,mdlc and i18n, does “MDL editing” refer to one of these?

this is no separate tool but a functionality of the API.
the tools do the following:
i18n is for creating localization files to help translating MDL content to different languages.
mdlc is a standalone compiler/syntax checker
mdlm if for creating mdl archives

for creation of function instances and editing of arguments and connecting functions and materials together please see

examples\mdl_sdk\instantiation
examples\mdl_sdk\calls

The result of the editing can be written to disk using
mi::neuraylib::IMdl_compiler::export_module

1 Like
32

Hi jjordan,

Thank you very much for the information.