1. Topics
  2. OSL getmessage/setmessage

OSL getmessage/setmessage

elizabeth.bonnefoy@...
 

 

Hi everyone!

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.
So we succeed to retrieve additional outputs from texture3d() with something like that:

result = texture3d(...);

getmessage("trace", "texture3d_out0", out0);

getmessage("trace", "texture3d_out1", out1);

 

But the first part is problematic, because the setmessage() feature seems to be private. There is no available definition of setmessage() in RendererServices, so we can't override it to use the "trace" source.
Ideally we would like to use it like that:

 

setmessage("trace", "texture3d_arg0", arg0);
setmessage("trace", "texture3d_arg1", arg1);
result = texture3d(...);


Maybe there is an other way to communicate from an OSL shader to a RendererServices functions?

Thank you for your help.
Kind regards,
Zab

 
Chris Kulla
 

Hi Elizabeth,

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?

Cheers,
Chris





On Wed, Mar 3, 2021 at 8:30 AM <elizabeth.bonnefoy@...> wrote:

 

Hi everyone!

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.
So we succeed to retrieve additional outputs from texture3d() with something like that:

result = texture3d(...);

getmessage("trace", "texture3d_out0", out0);

getmessage("trace", "texture3d_out1", out1);

 

But the first part is problematic, because the setmessage() feature seems to be private. There is no available definition of setmessage() in RendererServices, so we can't override it to use the "trace" source.
Ideally we would like to use it like that:

 

setmessage("trace", "texture3d_arg0", arg0);
setmessage("trace", "texture3d_arg1", arg1);
result = texture3d(...);


Maybe there is an other way to communicate from an OSL shader to a RendererServices functions?

Thank you for your help.
Kind regards,
Zab

 
elizabeth.bonnefoy@...
 

Hi Chris

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.
We just wanted to know if there was a better way to do it, but we can deal with that.

Thank you again for your time.

Kind regards,

Zab
1 - 3 of 3