MDL dynamic textures


Is there any possibility to skip database path resolving for textures and load them from RAM? And if not, is there any possibility to get matching texture_id from compiled code for every texture_type parameter in material definition?

When resource is not connected to MDL material; texture parameter (visible in argument block) is equal (0x00,0x00,0x00,0x00) which is invalid type.

Should I pass texture pointer to this variable?

I’m using MDL SDK from github and compiling code to PTX.



Yes there is an option on the IMdl_execution_context to disable resource loading. It’s called ‘resolve_resources’. Set it to false when loading the module and while creating the compiled material or simply set it right after creating the context.

After generating the target code, you can iterate over all resources and resolve them yourself for eaxmple using our entity resolver, which is currently only an experimental feature of the API:

const char *resource_url = target_code->get_texture_url(texture_index);
const char *owner_module = target_code->get_texture_owner_module(texture_index);
const char *owner_module_file_name = NULL;
if (owner_module) {
    std::string owner_module_db_name = "mdl";
    owner_module_db_name += owner_module;
    mi::base::Handle<const mi::neuraylib::IModule> m(
        transaction->access<const mi::neuraylib::IModule>(owner_module_db_name.c_str()));
    owner_module_file_name = m->get_filename();

mi::base::Handle<mi::neuraylib::IMdl_entity_resolver> entity_resolver(

mi::base::Handle<mi::neuraylib::IMdl_resource_set> result(
    entity_resolver->resolve_resource_file_name(resource_url, owner_module_file_name, owner_module));

if (result->get_count() == 0) {
    // Resource could not be resolved!
    return false;

// first texture or more in case of udim textures
const char *filename = result->get_filename(0);

Regarding the second part of questions, it seems your material contains invalid textures meaning “” (the empty string). Can you provide a bit more context?


Thank you krohmer,

Resolve resources option will be very helpful. About some context you asked for:

  1. Material which has empty string was created on purpose - no resource was added to tex2D input while designing material( texture2D x = texture2D() in mdl file).
  2. I’m looking for solution which doesn’t include reading filepaths written in mdl - instead I’m trying to make mdl-based package with texture metadata (name of variable and texture_id used in access texture methods). Entity resolver will be very useful in mentioned package validation.

I would like to ask for one more thing:

While class-compiling argument block contains data for VK_TEXTURE kind parameters. Name of each parameter corresponds with mdl texture input name. Byte size of all texture parameters is always 4 and bytes are set like in subsequent integers ([0x01,0x00,0x00,0x00];[0x02,0x00,0x00,0x00],… ].
This is code fragment I’m using for texture name,db name and id mapping:

int* idx = reinterpret_cast<int*>( + argument_offset);
 texture_map_.insert(std::pair<std::string, Texture>(name, Texture( + argument_offset, code_cuda_ptx->get_texture(*idx))));

Db names corresponds with parameter names and data stored in mdl. Two questions arise:

  1. Is this possible that this values (idx in code) are texture ids used in access texture methods?
  2. Does changing that four bytes will change access texture behavior or is it read-only?

EDIT: It seems that data stored in argument block is an int for texture idx. It worked for a few exemplary materials. I would like to ask if this is a coincidence or design?

EDIT2: ‘resolve_resources’ flag is possible to set (0 in return), but compiler return invalid material (error in console, NULL as return).

auto a = execution_context->set_option("resolve_resources", false);
  1. Is this possible that this values (idx in code) are texture ids used in access texture methods? (and EDIT)

Yes, these values are directly provided to the texture access methods as texture IDs.

  1. Does changing that four bytes will change access texture behavior or is it read-only?

Yes, changing the texture index in the argument block will allow you to use a different texture (known to your texture runtime). The df_cuda MDL SDK example allows you to choose between any texture loaded by the material for texture parameters. You could also load new textures not known to the material and provide their IDs, as long as you make your texture runtime knows them.

I’m not quite sure how to read your EDIT2, but the flag has to be set like this:

context->set_option("resolve_resources", false);