The NVIDIA MDL SDK is the C++ toolkit behind physically-based material pipelines

What MDL is and what the SDK is

The NVIDIA Material Definition Language (MDL) is a domain-specific programming language that you use to define physically-based materials and lights for rendering. It is designed for the definition of the highest quality materials, fast rendering, and serves as an industry standard for material exchange.

Three design goals in one sentence, and they pull against each other. Highest quality means the language has to be able to express a physically meaningful model rather than a set of texture slots. Fast rendering means that model has to be compilable. And being an industry standard for exchange means the format has to be open rather than tied to one renderer.

The MDL SDK is the toolkit that makes those goals reachable from an application. It is described as a toolkit delivered as an open-source C++ library, designed to support a wide range of material workflows in new or existing applications. The audience is software developers integrating MDL into applications with 2D or 3D graphics capabilities, and the prerequisite skills listed are a working knowledge of C++ and familiarity with fundamental 3D graphics concepts.

That audience statement is narrower than it first looks. This is a library for people building renderers or content tools, not for artists. The audience line also tells you what the SDK does not do: it does not ship an editor.

The primary language is C++, the licence is BSD-3-Clause, and the last push was on 2026-08-31, alongside the 2026.0.2 release dated 24 August 2026.

How an MDL material is written

Materials consist of two parts, a material definition and functions, and the split matters because the two are written in different styles.

The material definition is declarative and based on a robust material model. The example in the README is a single parameter feeding a BSDF:

export material diffuse( color diffuse_color = color(0.7))
    = material(
        surface: material_surface (
            scattering: df::diffuse_reflection_bsdf (
                tint: diffuse_color
            )
        )
    );

The declaration names a parameter, diffuse_color, and uses it as the tint of a diffuse reflection BSDF. Note that the language is expression-shaped rather than statement-shaped: the material equals a material expression, and the surface is a material_surface whose scattering is a BSDF whose tint is the parameter.

The functions are written in a procedural programming language and compute parameter values for the material model. The tiles example computes the colour of a tile at a particular texture coordinate to define a checkerboard:

export color tiles( int no_tiles,
                    color black = color(0.1),
                    color white = color(0.8))
{
    float3 uvw = step(0.5, frac( no_tiles/2 * state::texture_coordinate(0)));
    float black_or_white = frac((uvw.x + uvw.y)*0.5)*2.0;
    return lerp( black, white, black_or_white);
}

That is a texture-space checkerboard: take the texture coordinate, halve it by the tile count, take the fractional part, threshold it at 0.5, and use the two resulting values to pick between black and white. The two colours are parameters, so the same function serves any pair.

And then the composition, which is the part that shows why the two-part structure exists:

export material checker() = diffuse( tiles( 8));

One line, and it defines a checkerboard material with eight times eight tiles per UV unit square. The declarative definition reuses the procedural function, and the tiling density is a parameter of the function rather than of the material. That separation is what makes an MDL library composable: a library can publish functions, and an application can publish materials that combine them.

The language documentation lives outside the repository: the Material Definition Language Handbook at mdlhandbook.com, plus the full MDL documentation at raytracing-docs.nvidia.com.

The seven stages of the workflow

The example workflow figure in the README is described callout by callout, and the seven stages are the clearest available description of what the SDK actually does.

First, MDL modules. You use the module mechanism to package materials and functions for reuse, and an MDL module contains one or more material and function definitions. When you load a module, it is parsed and validated by the MDL compiler and its content is stored in an internal database.

Second, the internal database, which provides access to all material and function definitions.

Third, transactions and call graphs. You create, edit, and store material instances and function calls using transactions, and the results are stored in the internal database. From database entities, you can connect functions to material parameters and build call graphs that express complex materials.

Fourth, compiled materials. You can compile these graphs into a compact optimized representation, and the compilation step includes inlining of call expressions, constant folding, and the elimination of common subexpressions.

Fifth, distilling, which is a process for mapping or simplifying compiled MDL materials to more limited material models used by specific renderers.

Sixth, texture baking, which ensures optimal rendering performance for game engines.

Seventh, backends. A compiled material is the basis for code generation, and the SDK provides backends for CUDA PTX, LLVM IR, HLSL and GLSL, and native code generation for the CPU.

Two of those stages carry most of the engineering. The transaction and call graph layer is what makes an application able to edit a material interactively and then compile the result, which is a rather different problem from evaluating a script. And the distillation step is the reason MDL can serve both a path tracer and a game engine: the game engine's material model is a strict subset of the path tracer's, so the compiled material has to be mapped down to what the engine can actually execute.

The backend list is the part to weigh for a specific renderer. CUDA PTX and LLVM IR target a GPU path tracer, HLSL and GLSL target a real-time engine, and native CPU code covers a software renderer.

Installing it and the examples that teach it

Prebuilt MDL SDK packages for Linux, Windows, and macOS are available from the releases page, and INSTALL.md covers system requirements and build instructions for Building the MDL SDK from Source.

The repository layout shows what is in the package. There is a CMakeLists.txt at the root, a cmake/ directory, an mdl-config.cmake.in template and a vcpkg.json, so the SDK is consumable as a CMake package and its third-party dependencies are declared for vcpkg. There is src/ and include/ for the library itself, and doc/ for the documentation and the figures the README references.

The example programs are the part that actually teaches the workflow. The README states that the MDL SDK includes example programs that cover the complete integration workflow, from loading a module to rendering complete scenes, and that the example sources are located in examples/mdl_sdk. The table that follows lists each example against a goal, starting with Initialize the SDK and the start_shutdown example.

Alongside that there are other example directories: examples/mdl, examples/mdl_core, examples/mdl_python and examples/thirdparty. The mdl_python one is worth noticing, because it means the same MDL content can be driven from Python, which is how you would script a material generation or audit pipeline rather than only build a renderer.

The documentation is part of the SDK rather than separate from it. It includes a detailed MDL specification and conceptual, user, and API reference documentation, and the same set is accessible from the NVIDIA Ray Tracing Documentation website.

There is also a licensing detail that is easy to miss and worth a look for anyone shipping an application built on it. Alongside the main LICENSE.md there are LICENSE_IMAGES.md and LICENSE_THIRD_PARTY.md at the repository root, so the images in the documentation and the bundled third-party code have their own terms distinct from the BSD-3-Clause licence of the SDK code.

The release naming is unusually informative. The tags carry a build number, so the most recent is 2026.0.2 with build 391700.2276, before 2026.0.0 with build 391700.996 from June 2026 and 2025.0.5 from February 2026. The first number is the year, which means MDL versions track the calendar and a renderer that pins an MDL version is pinning a specific point in the language's development.

Where the MDL SDK fits, and where it stops

The comparison worth making is with writing an MDL parser yourself and with shipping materials in a native renderer format.

Against writing your own, the compiler and the database are the two hard parts. The MDL compiler parses and validates a module, and the internal database stores every definition and every transaction applied to it. An application that wants to let a user edit a material and then compile it needs both, and the call graph representation that connects functions to parameters is the third piece. Reimplementing that is not a weekend project, and it is precisely the part that would have to track the language's changes.

Against shipping native renderer formats directly, the difference is interchangeability. A material authored as MDL can be compiled for a path tracer and distilled for a game engine, and the source stays the source of truth. A material authored for one engine's native format has to be re-authored for another. That is the industry-standard argument the README makes, and it is the reason a tool like this exists at all.

The limits are worth naming. This is a C++ library, so it is not something you drop into a Python or Java service without a native binding, though the Python examples suggest the content can be reached that way. The SDK is aimed at applications with 2D or 3D graphics capabilities, and it provides no renderer of its own, so integrating it means embedding it in something else. The distillation step is where a simplified model has to be chosen, and any limitation of the target renderer's material model becomes a limitation of what an MDL author can express. And the README does not describe a compatibility matrix between MDL versions and specific renderers, so for a production pipeline that question is worth asking the documentation site.

On the ecosystem side, the surrounding resources are substantial: the MDL Handbook for the language, the NVIDIA Ray Tracing documentation for the SDK, and the linked module mechanism that lets libraries publish reusable functions.

The honest summary is that the MDL SDK is infrastructure rather than a product. It pays off if you are building a renderer or a content tool that wants to accept MDL assets, and it does nothing for you if you only want to make one material for one engine.

Editorial conclusion

The MDL SDK suits a renderer or DCC tool vendor that wants to accept MDL assets without writing an MDL implementation, since the SDK provides the compiler, the internal database, the code generation backends and the texture baking rather than only the file format. It is the wrong tool if you want to write materials rather than consume them, because authoring happens in MDL source, and it is the wrong tool if your renderer is not one of the target platforms, since the backends target CUDA, LLVM, HLSL, GLSL and native CPU code specifically. Before you build it, read INSTALL.md for the system requirements, and check the examples under examples/mdl_sdk, which the README describes as covering the complete integration workflow from loading a module to rendering complete scenes.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. NVIDIA/MDL-SDK on GitHub
4. README
5. Releases