Results 1 to 5 of 5

Thread: MDL SDK general questions

  1. #1
    Join Date
    Mar 2018
    Posts
    6

    Default MDL SDK general questions

    Hey all,

    I have a few general questions regarding the SDK:
    • Is there any way to access the code from base.mdl to understand how it was built and what it exactly does?
    • Is it possible to prevent a specific mdl module from being inlined during compilation? (the base module isn't for example)
    • I see it is possible to generate PTX code for a BSDF since SDK 2018, can we also do that for GLSL by any chance? The function 'translate_material_df' is attached to a 'backend' object so it should be possible but it doesn't seem to work. I managed to convert a BSDF to PTX but the same code with GLSL backend yields the following error: "Only distribution functions are allowed" (error code -5). I don't suppose this is supposed to happen.
    • Are the BSDFs' code available somewhere so that we can implement our own mdl interpreter that is consistent with Iray?
    • Finally, do we also know what the implementation of the fresnel function in fresnel_layer and curve in color_custom_curve_layer are?

    Thank you very much in advance,

    Fran├žois
    Last edited by frguthmann; May 3rd, 2018 at 18:32. Reason: Forgot one question

  2. #2
    Join Date
    Jan 2007
    Posts
    314

    Default

    > Is there any way to access the code from base.mdl to understand how it was built and what it exactly does?
    At the moment i can not share the full source of base.mdl. If you have specific questions to individual functions, i can share parts.
    >Is it possible to prevent a specific mdl module from being inlined during compilation? (the base module isn't for example)
    I assume that you talk about inlining of functions? Functions that contain control flow are not inlined. There is also an inofficial annotation to signal our compiler anno::noinline(), see for example in alg::base::normalmapping.mdl for usage.
    > I see it is possible to generate PTX code for a BSDF since SDK 2018, can we also do that for GLSL by any chance?
    unfortunately thats not so simple. For a ray- or pathtracer, the interface for the bsdf is pretty well defined. this is less so for a GLSL renderer. Its also unclear if you would want to evaluate an arbitrary complex bsdf in a realtime context.
    https://github.com/nvpro-pipeline/pi...r/apps/mdl2xml has code to generate glsl code for a full material. consider this a blueprint.
    In a realtime context i personally would suggest to implement a UE4 material model and use distilling to drive the inputs. We do work on a dedicated sample for that.
    >Are the BSDFs' code available somewhere so that we can implement our own mdl interpreter that is consistent with Iray?
    The implementation details for the bsdf are referenced in the spec bibliography. We work on sharing more straightforward reference implementations with you (this is true also for the layering).
    Jan

  3. #3
    Join Date
    Mar 2018
    Posts
    6

    Default

    Hey Jan, thank you for your answer!

    > At the moment i can not share the full source of base.mdl. If you have specific questions to individual functions, i can share parts.
    Well I was hoping I could get the entire source haha. Thanks anyway!

    >I assume that you talk about inlining of functions? Functions that contain control flow are not inlined. There is also an inofficial annotation to signal our compiler anno::noinline(), see for example in alg::base::normalmapping.mdl for usage.
    I'm sorry my question wasn't very clear, I might have overlooked the problem. It's probably easier if I give you the entire use case.
    I created a material called 'metal' in its own file. In another file, I use 'metal' to create another material called 'custom_metal' and I fill its inputs using the procedural programming language.

    Code:
    export material custom_metal()
     = 
        let {
            color tmp0 = ::base::file_texture(texture_2d("./metal/metal_resource_0.png", ::tex::gamma_srgb), color(0.f, 0.f, 0.f), color(1.f, 1.f, 1.f), ::base::mono_average, ::base::transform_coordinate(::base::rotation_translation_scale(float3(0.f), float3(0.f), float3(1.f)), ::base::texture_coordinate_info(::state::texture_coordinate(0), ::state::texture_tangent_u(0), ::state::texture_tangent_v(0))), float2(0.f, 1.f), float2(0.f, 1.f), ::tex::wrap_repeat, ::tex::wrap_repeat, false).tint;
            float tmp1 = ::base::file_texture(texture_2d("./metal/metal_resource_1.tif", ::tex::gamma_default), color(0.f, 0.f, 0.f), color(1.f, 1.f, 1.f), ::base::mono_average, ::base::transform_coordinate(::base::rotation_translation_scale(float3(0.f), float3(0.f), float3(1.f)), ::base::texture_coordinate_info(::state::texture_coordinate(0), ::state::texture_tangent_u(0), ::state::texture_tangent_v(0))), float2(0.f, 1.f), float2(0.f, 1.f), ::tex::wrap_repeat, ::tex::wrap_repeat, false).mono;
        } in
            ::metal::metal(
                albedo: tmp0,
                metallic: tmp1,
               );
    Now when I compile 'custom_metal' and dump the produced mdl code, (as in example_traversal of the SDK) 'metal' is replaced by its actual mdl code and some of the inputs of 'custom_metal' are inserted within this code. This is an extract of the 'custom_metal' once compiled:
    Code:
    } in material(/*constructor*/ 
    (...)
    layer: ::df::directional_factor(/*call*/
                normal_tint: ((temporary_4 * temporary_2) + (::base::file_texture(/*call*/
                        texture: texture_2d("/metal/metal_resource_4.png", gamma: ::tex::gamma_default),
    
    -------------------------------------------------
    
    float temporary_2 = ::base::file_texture(/*call*/
          texture: texture_2d("/metal/metal_resource_1.tif", gamma: ::tex::gamma_default),
          color_offset: color(0.000000f, 0.000000f, 0.000000f),
          color_scale: color(1.00000f, 1.00000f, 1.00000f),
          mono_source: ::base::mono_average/*enum of type: '::base::mono_mode'*/,
          uvw: temporary_1,
          crop_u: float2(0.000000f, 1.00000f),
          crop_v: float2(0.000000f, 1.00000f),
          wrap_u: ::tex::wrap_repeat/*enum of type: '::tex::wrap_mode'*/,
          wrap_v: ::tex::wrap_repeat/*enum of type: '::tex::wrap_mode'*/,
          clip: false
        ).mono;
    As you can see, 'normal_tint' uses temporaries and a call to file_texture. Both the temporaries and the file_texture calls were inputs to 'custom_metal'. What I would want, is to be able to only parse the inputs of the 'custom_metal' material using the SDK. Right now, it will replace 'metal' by its mdl code (Ex: layer: ::df::directional_factor) and insert some of 'custom_metal' inputs in it. (Ex: ::base::file_texture(/*call*/)
    The point of all this is to let people design mdl material inputs that feed our 'custom_metal' material and have consistency across several engines: in real-time using our custom glsl approximation of the 'metal' material and in Iray using vanilla mdl. This is why I wanted the 'custom_material' not to be inlined at compilation but I see now it's not that simple.
    It's a bit complicated because I still need the material to be compiled to resolve eventual dependencies before parsing it, yet I don't want 'custom_metal' to be compiled.
    PS: I could not find alg::base::normalmapping.mdl, could you upload it somewhere?

    >Its also unclear if you would want to evaluate an arbitrary complex bsdf in a realtime context.
    Ideally yes. It would not be really fast of course but at least it would be accurate. It would also help me understand the actual implementations of the papers mentioned in the specification.

    >In a realtime context i personally would suggest to implement a UE4 material model and use distilling to drive the inputs. We do work on a dedicated sample for that.
    I'm afraid this is not accurate enough for some scenarios but a great fallback solution. Also, a little more documentation on how to recreate the material in UE using the distilled inputs would be great.

    >The implementation details for the bsdf are referenced in the spec bibliography. We work on sharing more straightforward reference implementations with you (this is true also for the layering).
    That would be amazing .

    Thanks again you for your fast reply!
    Last edited by frguthmann; May 4th, 2018 at 12:23.

  4. #4
    Join Date
    Jan 2007
    Posts
    314

    Default

    Quote Originally Posted by frguthmann View Post
    Hey Jan, thank you for your answer!

    > At the moment i can not share the full source of base.mdl. If you have specific questions to individual functions, i can share parts.
    Well I was hoping I could get the entire source haha. Thanks anyway!
    dont give up hope
    Quote Originally Posted by frguthmann View Post
    >I assume that you talk about inlining of functions? Functions that contain control flow are not inlined. There is also an inofficial annotation to signal our compiler anno::noinline(), see for example in alg::base::normalmapping.mdl for usage.
    I'm sorry my question wasn't very clear, I might have overlooked the problem. It's probably easier if I give you the entire use case.
    I created a material called 'metal' in its own file. In another file, I use 'metal' to create another material called 'custom_metal' and I fill its inputs using the procedural programming language.

    Code:
    export material custom_metal()
     = 
        let {
            color tmp0 = ::base::file_texture(texture_2d("./metal/metal_resource_0.png", ::tex::gamma_srgb), color(0.f, 0.f, 0.f), color(1.f, 1.f, 1.f), ::base::mono_average, ::base::transform_coordinate(::base::rotation_translation_scale(float3(0.f), float3(0.f), float3(1.f)), ::base::texture_coordinate_info(::state::texture_coordinate(0), ::state::texture_tangent_u(0), ::state::texture_tangent_v(0))), float2(0.f, 1.f), float2(0.f, 1.f), ::tex::wrap_repeat, ::tex::wrap_repeat, false).tint;
            float tmp1 = ::base::file_texture(texture_2d("./metal/metal_resource_1.tif", ::tex::gamma_default), color(0.f, 0.f, 0.f), color(1.f, 1.f, 1.f), ::base::mono_average, ::base::transform_coordinate(::base::rotation_translation_scale(float3(0.f), float3(0.f), float3(1.f)), ::base::texture_coordinate_info(::state::texture_coordinate(0), ::state::texture_tangent_u(0), ::state::texture_tangent_v(0))), float2(0.f, 1.f), float2(0.f, 1.f), ::tex::wrap_repeat, ::tex::wrap_repeat, false).mono;
        } in
            ::metal::metal(
                albedo: tmp0,
                metallic: tmp1,
               );
    Now when I compile 'custom_metal' and dump the produced mdl code, (as in example_traversal of the SDK) 'metal' is replaced by its actual mdl code and some of the inputs of 'custom_metal' are inserted within this code. This is an extract of the 'custom_metal' once compiled:
    ...
    As you can see, 'normal_tint' uses temporaries and a call to file_texture. Both the temporaries and the file_texture calls were inputs to 'custom_metal'.
    hmm, no. they were temps in custom_metal as far as i see. if you want it to stay parameters you needt use class compilation mode and custom metal should look like:
    Code:
    export material custom_metal(
        color albedo = ::base::file_texture(...).tint,
        color metallic = ::base::file_texture(...).tint)
     =  ::metal::metal(
                albedo: albedo,
                metallic: metallic,
               );
    or

    Code:
    export material custom_metal(*)
     =  ::metal::metal(
                albedo: ::base::file_texture(...).tint,
                metallic: ::base::file_texture(...).tint,
               );
    the second construct is a so called material variant.
    the result of compilation will always be a "material struct" with a flattened bsdf structure. Depending on whether you use instance or class compile , parameters will stay parameters. If a parameter is of type "material" though, some more complex transform will happen.

    in general compilation is fast. You could also consider editing parameters before compilation.
    Quote Originally Posted by frguthmann View Post


    PS: I could not find alg::base::normalmapping.mdl, could you upload it somewhere?
    best is to download the material exchange from the bottom of
    https://www.nvidia.com/en-us/design-...tion-language/
    it contains all 3rd party modules, including the allegorithmic ones.

  5. #5
    Join Date
    Mar 2018
    Posts
    6

    Default

    Quote Originally Posted by JanJordan View Post
    dont give up hope
    Nice!

    Quote Originally Posted by JanJordan View Post
    hmm, no. they were temps in custom_metal as far as i see. if you want it to stay parameters you needt use class compilation mode and custom metal should look like:
    Code:
    export material custom_metal(
        color albedo = ::base::file_texture(...).tint,
        color metallic = ::base::file_texture(...).tint)
     =  ::metal::metal(
                albedo: albedo,
                metallic: metallic,
               );
    or

    Code:
    export material custom_metal(*)
     =  ::metal::metal(
                albedo: ::base::file_texture(...).tint,
                metallic: ::base::file_texture(...).tint,
               );
    the second construct is a so called material variant.
    the result of compilation will always be a "material struct" with a flattened bsdf structure. Depending on whether you use instance or class compile , parameters will stay parameters. If a parameter is of type "material" though, some more complex transform will happen.
    in general compilation is fast. You could also consider editing parameters before compilation.
    By inputs I didn't mean parameters but more like separable variables that are outside of the material code. This is the beginning of a solution. Unfortunately, since in the end the compilation always returns a "material_struct" it's not enough. I need to think a little bit more about what I want to do and how to do it. This helped a lot, thank you.

    Quote Originally Posted by JanJordan View Post
    best is to download the material exchange from the bottom of
    https://www.nvidia.com/en-us/design-...tion-language/
    it contains all 3rd party modules, including the allegorithmic ones.
    I had it already, didn't know it was there. I was looking in the Substance folders which don't have this file for some reason.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •