Page 3 of 3
Re: OctaneRender for HoudiniSolaris 2026.1.0.1
Posted: Thu Feb 19, 2026 10:02 pm
by joanna_xform
Light passes in this release are unusable, I'm not even sure where to begin explaining just quite how bizarrely broken they are - for example things like changing the order in which the light nodes are connected to the tree appear to affect the results.
The primvars seem to be getting assigned correctly, but this isn't reflected in the render.
Re: OctaneRender for HoudiniSolaris 2026.1.0.1
Posted: Thu Feb 19, 2026 11:53 pm
by BK
joanna_xform wrote: Thu Feb 19, 2026 10:02 pm
Light passes in this release are unusable, I'm not even sure where to begin explaining just quite how bizarrely broken they are - for example things like changing the order in which the light nodes are connected to the tree appear to affect the results.
The primvars seem to be getting assigned correctly, but this isn't reflected in the render.
Hi Joanna,
Thank you so much for the post.
Are you using the Light pass ID under the Octane>Visibility tab?
It would be nice if you could share a sample scene for us to investigate.
Cheers!
Re: OctaneRender for HoudiniSolaris 2026.1.0.1
Posted: Mon Feb 23, 2026 11:32 am
by joanna_xform
BK wrote: Thu Feb 19, 2026 11:53 pm
joanna_xform wrote: Thu Feb 19, 2026 10:02 pm
Light passes in this release are unusable, I'm not even sure where to begin explaining just quite how bizarrely broken they are - for example things like changing the order in which the light nodes are connected to the tree appear to affect the results.
The primvars seem to be getting assigned correctly, but this isn't reflected in the render.
Hi Joanna,
Thank you so much for the post.
Are you using the Light pass ID under the Octane>Visibility tab?
It would be nice if you could share a sample scene for us to investigate.
Cheers!
Before I spend time making a repro scene, were the light passes working correctly in your internal test files...? This issue is very obvious to me even in a simple setup, and it would be difficult for me to cover every possible permutation of it anyway. I'm also not the only one having this problem - someone else in this thread mentioned this too.
Re: OctaneRender for HoudiniSolaris 2026.1.0.1
Posted: Mon Feb 23, 2026 7:07 pm
by adrianr
Master_39 wrote: Thu Jan 29, 2026 11:54 am
adrianr wrote: Thu Jan 29, 2026 11:42 am
Hey Bikram,
I wonder if we're talking about different things here. I have attached another screenshot.
Something is happening between the output from Octane and how that image is interpreted in the Solaris viewport. The input texture is ACEScg. It's tagged as ACEScg. Nuke displays this as expected, so does Karma, so does the standard Octane Houdini plugin and so does Octane standalone. All images are being viewed with the same OCIO config view transform. Even if Houdini itself were somehow using a different config it wouldn't explain the difference between the standard plugin and Solaris. The outlier is the Solaris viewport, which renders the image too saturated. This is not an issue limited to or related to texture colourspaces however, as you can take any arbitrary light or geometry, set an RGB value on it, and it will render differently (Between the standard plugin and Solaris, or between standalone and Solaris, either or. My previous screenshot shows this with a light).
Are you saying that on your end if you run the same image or colour through the regular plugin and Solaris that you get the same result? Because that's definitely not what I'm seeing here.
H21_Octane_Solaris_colour_issues_02.jpg
Hi,
To fix the Solaris viewport issue, this is what worked for me.
I went into the OCIO Editor and left the Render Working Space set to Linear, because Octane always expects linear images.
Then I changed the View Transform and set it to ACES 1.0.
After doing this, the Solaris viewport matches perfectly with the Octane viewport in the standalone version.
So try this setup and see if it matches on your side!
Thank you for the post Master_39! This does indeed work, although I'm still not 100% sold on this being a full solution. Part of that could be blamed on Houdini's inability to set a working space separate to your OCIO config scene_linear role, so that is what it is. Though it is a pain that Octane in Houdini basically isn't able to use the same OCIO config we set project wide that every other program is looking at. I wonder if Octane could start looking for a specific role to be used in place of scene_linear, much like Substance has a bunch of roles it looks for that can override more typical roles you'd find.
I would still really like to know what Standalone and Sops are doing under the hood to make this a non-issue. Are they sending out ACEScg primaries from the Imager (This is what handles the mapping from spectral to an actual output space, right? And what the 'Intermediate Colour Space' field is for?). Or are they also still outputting Linear Rec.709 and the OCIO config plays no role in how the viewport interprets the data like it does in Solaris? And the resulting EXR colourspace is only set on output?