I'm a R&D engineer at Illumination MacGuff, and i'm currently trying to use the setmessage() / getmessage() feature from OSL.
To provide a bit of context: we are creating an OSL shader to read our volume files using an override of the RendererServices::texture3d() function for the lookup in the file.
From this OSL shader, we would like to provide some additional arguments to the texture3d() call, and get back some informations from this call which are not in the available values returned by texture3d().
Maybe it is a bad idea - feel free to give me your advice - but we are trying to use setmessage() and getmessage() to do it, and the second part actually works very well: thanks to an override of the RendererServices::getmessage(), we can use the "trace" source to communicate between functions in RendererServices and the OSL shader.
toggle quoted messageShow quoted text
I think getmessage is probably not the easiest way forward here. Generally we try to avoid calls that require holding onto state as much as possible (the trace call and getmessage being notable exceptions). In fact you probably noticed already that only the "trace" related getmessage calls will make it to render services. There isn't currently a form of setmessage that will invoke anything on the renderer services side.
It's a bit hard to say without knowing all the details of your use case - but perhaps you could take advantage of the "firstchannel" or "subimage" arguments to the texture call? This would allow you to return different values for different calls to texture3d. Or is there something about your use case that requires you to perform all the work in a single call to texture3d?
Can you give us a few more details about what you would like to pass in and out of the texture3d call?
On Wed, Mar 3, 2021 at 8:30 AM <elizabeth.bonnefoy@...> wrote:
Thank you for your answer!
To give you more context, we try to read volumetric files from OpenVDB via texture3D(), so we need to provide it some arguments like:
- The name of the VDB file, which can hold many grids
- The name of the grid we want to read: "Density", "Heat", "LevelSet", ...
- Some lookup options, like using multi-resolution or not, some multiplicative scale on the filter size, access to the min/max grid useful for the tracking algorithm...
- Eventually the name of some metadata we would like to retrieve from the file
Actually it's ok, because as you said it, there is always an argument of texture3D we can use to provide additional informations, even if this could lead to several call to texture3D() for the same file.
Thank you again for your time.