Why does IMdl__backend::translate_material_expression require an ITransaction?

My learning expedition continues :)

It looks like a lot of methods in the SDK require an ITransaction, but I’m lacking an understanding of why this is.

Specific example, once I have a compiled material, why do I need an ITransaction to run IMdl__backend::translate_material_expression()? In comparison, IMaterial_instance::create_compiled_material() doesn’t need an ITransaction.

I’m imagining one reason would be if translate_material_expression() always stores the ITarget_code in the DB. But that seems strange to me.

Thanks for putting up with my rookie questions!

In general, except for IMdl_compiler::load_module, no function “secretly” stores data into the database. It is up to the API user to do so via ITransaction::store().

So, all functions with a transaction parameter contain read-only accesses of one or the other element in the data base. In this particular case, IMdl__backend::translate_material_expression(), accesses the module of the material instance and potentially function calls referenced in its arguments.

Actually, data base elements, derived from IScene_element, store a pointer to the transaction that was used to access them, therefore you do not need to pass in a transaction when calling for example IMaterial_instance::create_compiled_material. Which means for the case of IMdl__backend::translate_material_expression(), one could use the transaction in the ICompiled_material parameter, which has to be the same as the one passed in explicitly. We chose to have an explicit transaction parameter to make in the API already clear that this function accesses the data base.

Thanks, that’s useful.

A tangential question: what’s the best way to store compiled code (i.e., the result of translate_material_expression())? transaction->store(native_code) won’t compile because native_code=translate_material_expression() returns a const*. I can do a const-cast, but that approach scares/worries me.

  • Rob

The method returns an object with the mi::neuraylib::ITarget_code interface, which is not derived from mi::neuraylib::IScene_element and cannot be stored in the data base. We recommend to just keep it locally with the other renderer specific data.

The data base comes originally from the iray system where it also supports distribution among multiple hosts, but there we would rather recommend a multi-host architecture where each host compiles to their specific backends and does not send the compiled results around.