OctaneRender for HoudiniSolaris 2026.4.0.0

[frankserin]

Hi there,

I'm working on a scene where you can see the "Visibility" issues because the original scene couldn't be shared with you. I wiil send you very soon.

Meanwhile, I'm experiencing a new bug/crash with Octane and particles. The crash occurs every time I start the IPR in Solaris, before the first image is rendered. Houdini reports a Segmentation Fault and creates a recovery file.

The crash does not appear to originate from Houdini itself, but from Octane during IPR initialization, possibly while setting up the render target.

Scene about new bug/crash: https://drive.google.com/file/d/1fldFy0_zOF87b9RpzCP2rizWojPXaBg1/view?usp=drive_link

[frankserin]

Hi there again, sorry for posting so much, but I keep finding more things that I feel aren't working.

I've been spending more time exploring Octane for Solaris, and the more I use it, the more I find features that are missing or don't integrate well with the Solaris workflow.

One example is Copernicus. Houdini's native workflow relies on `op:` paths to reference COP textures directly, but Octane doesn't seem to support them. If `op:` isn't supported, how are we supposed to use Copernicus procedurally inside Octane for Solaris? Is there any workflow I'm missing?

Another limitation I found is the lack of basic HDRI color controls. There doesn't seem to be any way to adjust exposure, saturation, or other color corrections for an HDRI used in an Octane Dome Light.

In Karma, this can be solved using Light Filters, allowing artists to tweak the lighting without modifying the original HDRI. Octane doesn't appear to offer an equivalent solution.

It would be great if Octane could support these native workflows more completely. Right now these feel like unnecessary limitations in day to day production. Thanks!

[BK]

Hi there,

I'm working on a scene where you can see the "Visibility" issues because the original scene couldn't be shared with you. I wiil send you very soon.

Meanwhile, I'm experiencing a new bug/crash with Octane and particles. The crash occurs every time I start the IPR in Solaris, before the first image is rendered. Houdini reports a Segmentation Fault and creates a recovery file.

The crash does not appear to originate from Houdini itself, but from Octane during IPR initialization, possibly while setting up the render target.

Scene about new bug/crash: https://drive.google.com/file/d/1fldFy0_zOF87b9RpzCP2rizWojPXaBg1/view?usp=drive_link

Hi there,

Thank you so much for the scene.

We are able to replicate the Segmentation Fault issue with the latest release.
We have created an internal ticket for our developer to investigate.

It looks like we can import the cache but not the out node for some reason.
We hope to get this fixed asap..

Cheers

[BK]

Hi there again, sorry for posting so much, but I keep finding more things that I feel aren't working.

I've been spending more time exploring Octane for Solaris, and the more I use it, the more I find features that are missing or don't integrate well with the Solaris workflow.

One example is Copernicus. Houdini's native workflow relies on `op:` paths to reference COP textures directly, but Octane doesn't seem to support them. If `op:` isn't supported, how are we supposed to use Copernicus procedurally inside Octane for Solaris? Is there any workflow I'm missing?

Another limitation I found is the lack of basic HDRI color controls. There doesn't seem to be any way to adjust exposure, saturation, or other color corrections for an HDRI used in an Octane Dome Light.

In Karma, this can be solved using Light Filters, allowing artists to tweak the lighting without modifying the original HDRI. Octane doesn't appear to offer an equivalent solution.

It would be great if Octane could support these native workflows more completely. Right now these feel like unnecessary limitations in day to day production. Thanks!

Hi there,

No worries..
The `op` paths are already supported however, it requires to reload when we make changes.
We are aware of this issue and will get it resolved in future.

We are currently discussing if there is a workaround to support the Light Filters node.

For now, please use the HDRI color controls or use the Octane HDRI environment settings.
Our developer is doing his best to support the native nodes since the beginning.

cheers

[frankserin]

Hi there again, sorry for posting so much, but I keep finding more things that I feel aren't working.

I've been spending more time exploring Octane for Solaris, and the more I use it, the more I find features that are missing or don't integrate well with the Solaris workflow.

One example is Copernicus. Houdini's native workflow relies on `op:` paths to reference COP textures directly, but Octane doesn't seem to support them. If `op:` isn't supported, how are we supposed to use Copernicus procedurally inside Octane for Solaris? Is there any workflow I'm missing?

Another limitation I found is the lack of basic HDRI color controls. There doesn't seem to be any way to adjust exposure, saturation, or other color corrections for an HDRI used in an Octane Dome Light.

In Karma, this can be solved using Light Filters, allowing artists to tweak the lighting without modifying the original HDRI. Octane doesn't appear to offer an equivalent solution.

It would be great if Octane could support these native workflows more completely. Right now these feel like unnecessary limitations in day to day production. Thanks!

Hi there,

No worries..
The `op` paths are already supported however, it requires to reload when we make changes.
We are aware of this issue and will get it resolved in future.

We are currently discussing if there is a workaround to support the Light Filters node.

For now, please use the HDRI color controls or use the Octane HDRI environment settings.
Our developer is doing his best to support the native nodes since the beginning.

cheers

Hi there,

Thank you very much for looking into these issues and for taking the time to investigate my reports. I really appreciate how responsive the team has been to my feedback.

I hope the next releases will bring a much more stable and complete Solaris experience, as it's a workflow with a lot of potential. Thanks again for your time, patience, and all the effort you're putting into improving the plugin. It's greatly appreciated.

Cheers!

[AlexeyAdamitsky]

I honestly do not understand the current state of the Octane integration with Solaris. Too many exposed features simply do not work or behave inconsistently.

Octane may be one of the best render engines available in terms of image quality, but its Solaris integration is deeply disappointing.
Is there an actual roadmap to make the Solaris integration reliable and fully functional?

Thanks for sharing your experience. I was using Octane exclusively in 2025 for the full year and it was exactly my experience as well. Constantly battling with bugs and workflow issues. Very poor Solaris/USD integration. I decided to skip 2026 and now was looking to get back for 2027 but I guess I won't. Looks like not much have changed and it's still not ready for full production if you're working fully in USD pipeline which is the new norm in Houdini. Maybe 2028 then. Too bad because I really enjoyed the speed and quality of the Octane. Not the user experience and bugs though.

[frankserin]

I honestly do not understand the current state of the Octane integration with Solaris. Too many exposed features simply do not work or behave inconsistently.

Octane may be one of the best render engines available in terms of image quality, but its Solaris integration is deeply disappointing.
Is there an actual roadmap to make the Solaris integration reliable and fully functional?

Thanks for sharing your experience. I was using Octane exclusively in 2025 for the full year and it was exactly my experience as well. Constantly battling with bugs and workflow issues. Very poor Solaris/USD integration. I decided to skip 2026 and now was looking to get back for 2027 but I guess I won't. Looks like not much have changed and it's still not ready for full production if you're working fully in USD pipeline which is the new norm in Houdini. Maybe 2028 then. Too bad because I really enjoyed the speed and quality of the Octane. Not the user experience and bugs though.

Considering your experience also, I honestly think Octane simply isn’t interested in Solaris. For those of us working in Houdini Solaris, the integration is a disaster. It feels like they released it just for the sake of having a Solaris integration, without providing any real support.

It’s already been more than a month since I reported these bugs, and they still haven’t even managed to release an update. With other renderers like Redshift, you usually get a new update within less than a month.

Considering that Houdini is moving away from the /obj workflow for rendering and that most of the new improvements are happening in Solaris, I don’t understand why Octane hasn’t done more to provide a proper implementation.

I’ve decided to stop using Octane and focus on Karma XPU instead. It’s genuinely fast, and I don’t have to waste time dealing with such stupid bugs in Solaris.

[BK]

I honestly do not understand the current state of the Octane integration with Solaris. Too many exposed features simply do not work or behave inconsistently.

Octane may be one of the best render engines available in terms of image quality, but its Solaris integration is deeply disappointing.
Is there an actual roadmap to make the Solaris integration reliable and fully functional?

Thanks for sharing your experience. I was using Octane exclusively in 2025 for the full year and it was exactly my experience as well. Constantly battling with bugs and workflow issues. Very poor Solaris/USD integration. I decided to skip 2026 and now was looking to get back for 2027 but I guess I won't. Looks like not much have changed and it's still not ready for full production if you're working fully in USD pipeline which is the new norm in Houdini. Maybe 2028 then. Too bad because I really enjoyed the speed and quality of the Octane. Not the user experience and bugs though.

Hi Alexey,

Thank you for the post and feedback.
Would you please share some of the hurdles or blockages faced while you were testing?
It will help us a lot.

We have been integrating Octane close to native Solaris workflow.
There was indeed slowdown due to Material unification plus the bugs fixes introduced with Hydra 2.

We are planning to work on stability moving forward to Octane 2027.

Looking forward to hearing soon!!

cheers

[AlexeyAdamitsky]

Would you please share some of the hurdles or blockages faced while you were testing?
It will help us a lot.

Not in the details, unfortunately. I was using Octane in Blender for at least a year or probably longer before moving to Houdini + Octane workflow. I had similar gripes there regarding UI/UX and how it integrates into Blender but it was fine. I could do work there. But then I was fully moving to Houdini and I wanted to keep using Octane. Unfortunately, my expirience was very poor:

1. Lack of documentation: Octane has a particular way of doing things so it's Solaris integration had quite a few hidden workflows that wasn't typical to general Houdini/USD workflow. There was no way of knowing this things so they could only be discovered if you ask support on a forum. Octane community is no help because at the time it seemed like the portion of people using Houdini + Octane was tiny so there were no one to ask around.
   So you would think the documentation would be the answer but there were berelly any useful information. Don't know if things changed or not. So I would strongly reccomend to implemented rigourous documentation process and updated it live constantly as the development integration goes. Otherwise it's extremly hard for new users to get on board if they want even try to use Octane in Solaris in the first place.
2. Poor UI/UX: I remember the feeling the many nodes had UI that wasn't really following the Houdini conventions. It wasn't always logical how it organized and behaved. The UI wasn't helping to make right decisions. For example, when you select one option in the setting that should hide or disable other sub-settings that doesn't work with the selected option makes it confusing. You need to put extra time to learn those setting dependencing.
3. Bad material building expirience: I believe it was missing proper material builder node which made it painfull to build Octane specific materials in Solaris since all the nodes were presented to you.
4. Weak MaterialX support: I don't remember but I think Octane didn't support MaterialX at the time which is a huge deal. I see no sense sticking to exclusing shading networks. At our projects we try to stick to MaterialX as much as we can unless something specific can't be done then we can fall back to Karma materials. Octane should follow the model. Make the MaterialX a priority and support it as much as possible but also keep Octane materials for now untill the MaterialX is that mature that we can all stick only to MaterialX. Which won't happen anytime soon, but still. MaterialX support should be a priority.
5. Poor USD support: A lot of examples but one sticking out the hardest was the instances support. I was doing a project and it was a pain to optimize it using instances since Octane couldn't recognize point instances properly and read attributes from them.
6. Lighting: While lighting in Octane is beautiful the tools itselft takes some time to love since historically Octane didn't follow the usual conventions how the lights are objects. You had to know these Octane quircks to work with lights effectively. I think it was changing at a time but I am not shure where Octane now with the lights and how well it supports USD lights schema and upcoming USD Lux schema for illumination values.
7. AOVs & Output: I remember it was giving me a lot of grief to get and easy acces to AOVs and output what I needed in a simple way. I think no LPE support either.
8. Performance: Not the Octane rendering but the interaction between Solaris and Octane. As I understood Octane couldn't just stream USD scene it had to load into memory fully. That made any viewport changes unpredictable. Ofthen changes made to the scene got stuck in an active viewport render so it wasn't as interactive as one would hope. You hard to hard refresh it to make sure things are updated.
9. OCIO: I don't remember specifics now but I remeber having issues with Octane to properly recognize OCIO configs and correctly apply rules to the files for correct color space conversions.

So while Octane render engine is fast and beutiful working with it was slow and painful in Solaris. Dealing with tons of unnowns and constant issues. Which nullifies the render speed benefits. So the reason to move on to other render engines.