Thank you krohmer,
Resolve resources option will be very helpful. About some context you asked for:
- 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).
- 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_block_.data() + argument_offset);
texture_map_.insert(std::pair<std::string, Texture>(name, Texture(argument_block_.data() + argument_offset, code_cuda_ptx->get_texture(*idx))));
Db names corresponds with parameter names and data stored in mdl. Two questions arise:
- Is this possible that this values (idx in code) are texture ids used in access texture methods?
- 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);