Omniverse for Blender 3.3 LTS?

What if I want to use Omniverse for a project that’s version locked to Blender 3.3 LTS?

Is this a feature that’s still just in development hence the branch, or is there a way to use this on production now?

If it’s possible to use with 3.3, what are the limitations and are there any guides?

Hello @sacb0y! Right now, our official Blender Connecter is still under development. If you would like to use our special Blender Application that has been formatted specifically for Omniverse, you can download it through the Omniverse Launcher. The current version is Blender 3.6 alpha USD branch 3.6.0-usd.200.0. We currently only have Blender version 3.6 in our release builds.

You can import your files from Blender into Omniverse. You can find more information on this here: Blender — Omniverse Connect documentation

Is there any eta on an official release? For me using beta or newer versions of Blender is risky cause of the assets and plugins I use. I have to version lock to LTS versions to ensure things stay compatible and workflow doesn’t need to change.

I guess I could open USD directly, but that’s not ideal for my needs based on the way omniverse seems to work…

I’d be curious to hear what specific assets and plugins don’t work with the OV Blender build. I could see some Python Add-ons needing updating but overall your experience shouldn’t be that different, and if it is we’d love to know what the pain points are.

For various reasons I can’t speak on here, our branch runs very close to Blender’s main branch. There are times when certain new features make the main branch unstable, and when that’s happened in the past we did not bring those features in. We test for stability on our end, and try to version up when things stabilize on the main branch.

If you really, really can’t stray from the 3.3 LTS release (and I get it-- I spent a lot of time in film/animation/vfx), what is preventing you from running both and using the OV Blender build to export into Nucleus / Omniverse apps? Is it the plugins you mentioned, or some other incompatibility?

Certain rigging assets I use mostly, there’s an asset we use called Auto Rig Pro that frequently breaks with new blender versions, and also their FBX export behavior changes which can cause problems in a big game project. Additionally, those updates can cause changes to the rig, it’s just too risky.

As such I try to stick with one version for as long as possible. There’s also other tools used for creating animations that can also break (retime, anim-aide, etc). In the end it’s more reliable to stick to an LTS.

But yeah a lot of this is due to Python and API changes.

I’ve also heard from some people newer versions can have issues with crashing during rendering. And where my goal here is to more easily use game environments to render higher fidelity animations and such, that would be a problem.

In the end I just don’t want to risk throwing a wrench in a working system, or having issues like someone accidentally saving a file in a newer version which while that usually works can cause issues.

Definitely the plugins not being compatible (and even if they are compatible often not working in reverse), along with not wanting issues like I said before where files accidentally end up with mixed versions.

I know part of this comes with still needing to use FBX for animations (One of the core reasons I use Auto Rig Pro is it’s custom exporter is reliable), but I’m not in a position to make that big of a workflow change to using more USD. At least not until we gain more experience with it.

I used to always use the latest blender version in the past, but now days I prefer reliability and consistency for our projects. So, I broadly stick to LTS versions like with our Unity game.

Primary reason I’m looking at this is cause the Unity connector came out. And I’d like a Unity > Omniverse > Blender solution for creating animations consistent with the game.

(assuming my other post comes out of the spam filter)

It’s worth noting I’m not against moving to whatever the latest LTS version is, which I think might be 3.6 once it’s released. Cause at least I know whatever issues faced in that transition will ultimately be resolved, and I won’t have to do it again unless I really need to.

And in that scenario using a special build of blender isn’t too absurd cause I know the plugins and such should work the same and not require updating any assets.

So if I need to use Blender 3.6 LTS when that’s released, and there’s an Omniverse version of 3.6 then that’s more reasonable for me.

Yeah unfortunately there’s nothing I can do to support Auto Rig Pro breaking between versions. As a rigger myself I get around this by maintaining my own tooling, but I understand that’s not an option for most. Provided you’re not using the Add-on UIs, though, you should still be able to animate the characters in any version.

I haven’t seen crashes at render time except when memory is exhausted. I’ve been part of two major projects using Cycles-- while it’s had its bugs, at this point it’s pretty stable.

I understand your reasoning. That said, I think the benefits of moving up outweigh the down sides and if you can sort out at least some of the incompatibilities, you might find that siloing off the parts of your pipeline that interact with Omniverse to still be worth it. If you hit any crashes or weirdness in the Blender build, or in the add-ons, please do post back with a repro case.

Fair enough but I imagine plenty of studios would be iffy about using non-LTS versions for a variety of reasons, stability being the biggest. And it might help with general adoption to consider it!

Hopefully I find something workable down the line that I feel more comfortable with transitioning to.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.