Hello all,
I am trying to create a GLSL node that is able to utilize the “depth.Z” channel in our EXR files. The documentation suggests using the “combine” evaluationType of node. I read the examples in the docs but they dont cover EXR layers. My parameters include :
string layer0 = “”
string layer1 = “depth”
After setting this up it worked and I was able to use the depth the channel. However I noticed that while this node seemed ok the next node in the chain (this node feeds into) was bugging out. The inputImage.size() function seems to receive intermittent garbage data, and there are intermittent errors about missing glsl parameters
“ERROR: Invalid attribute location in RenderPrimitives::render.”.
I came across this bug In the OpenRV git page:
https://github.com/AcademySoftwareFoundation/OpenRV/issues/481
This seems very similar to to my problems
My question is can anyone show me an example of the proper use of the “combine” node type for extracting EXR channels? Am I using it wrong or is it a bug?
I should also mention that where I put the node seems to have an effect. Putting the node after a sequence caused the above issues. Putting the node directly above the sourceGroup seemed more stable but causes other problems.
Any help will be most appreciated Thank you.
Running RV 2024.1.0 on Windows 11
Hi
I believe the issue you mentioned is due to something else.
I was trying to access the “.size()” inside the node which isn’t working with the combine node, but it didn’t give me any errors when using this node I believe.
Are you able to provide your .gto (and glsl) code?
Did you try working with a very minimal setup to see if it’s the node itself or your glsl code that’s causing the issue?
Cheers, Mirco
Wow thanks for the quick response…
The .size() function worked for me inside the combine node (not shown here), but my combine nodes feeds directly into another node, any node after the combine gets bad data in the .size() function and sometimes that error about attribute locations. Here is the code simplified a little:
==== GTO FILE ====
OShuffle : IPNodeDefinition (1)
{
node
{
string evaluationType = "combine"
string defaultName = "oshuffle"
int userVisible = 1
}
render
{
int intermediate = 0 # non-zero == cache the result
}
function
{
string name = "main"
string glsl = "file://${HERE}/OShuffle.glsl"
}
parameters
{
string layer0 = "depth"
string layer1 = ""
}
}
==== SHADER FILE ====
vec4 main (const in inputImage depth_in, const in inputImage rgb_in) {
const vec4 zpix = depth_in();
const vec4 rgbpix = rgb_in();
return vec4(rgbpix.rgb, zpix.r);
}
As I mentioned if I inject this node after the sourceGroup but before the defaultSequence then the problems go away… but new problems arise from the messy node structure.
Another point of interest is order in which I put the layers has an effect. for example if I put depth on “layer1” I seemed to have more issues, and the “Image Info” overlay displays only the depth layer, while putting it on “layer0” causes the layers / channels to display normally.
For completeness here is a simple example the the next node in the chain. This node is a “filter” type. You would expect this node to return some solid color. It does not. It blinks and changes as you change frames or even resize the viewport.
// The next "filter" node that comes after the shuffle above
vec4 main (const in inputImage in0) {
// testing the image size function is returning garbarge
vec2 img_sz = in0.size();
return vec4(img_sz.x / 6000.0, img_sz.y / 6000.0, 0.0, 1.0);
}