Well, if you request functions to be generated for an EDF, the backend will do so.
You could check, whether
ICompiled_material::lookup_sub_expression() returns an
surface.emission.emission. If so, the MDL just had
edf() for this field.
Then you could store the info, that no emission is needed, in the corresponding HitGroupData object.
Calling a no-op function is not for free. When using direct callables, this cannot be optimized away.
optixDirectCall() receives an index into the
callablesRecordBase array of your
OptixShaderBindingTable. You could use an obviously invalid index here, like MAX_INT, and check for that before calling
optixDirectCall(). It depends on your use case, whether this may be a better solution than a bool in the hit group data.
Btw, please make sure, you use the single-init mode when generating, as used the
df_cuda example. Then only one init function is generated for a set of expressions for one material and the precalculated values can be used by all those expressions. Otherwise you have to call one init function for the bsdf part and another for the edf part and some calculations may be done multiple times.
You can enable the single-init mode by using the special expression path
"init" as first element in the
mi::neuraylib::Target_function_description list, which you can provide to the
No, the documentation about the VDFs is correct, we don’t generate code for them.