I can see how USD is important for large studios with multiple departments, but I dare say there are many setups that will never go near USD. My concern is that more and more will need to be piped through Solaris, Karma being the prime example. It feels awkward and annoying to have to pipe my conventional job through an extra layer of complexity just to use Karma, so I'm still using Redshift.

The impetus to ask the question is Copenicus, very cool but is it going to be fully integrated or will I need to pay the Solaris tax? Same question goes for the future of Houdini in a broader sense.... will more than just Karma be locked out for non Solaris setups?


cheers,

A.

Andi Farhall
Copenicus

From the official demo you can clearly see Copernicus works fine in /obj:

That I could see but would op:/blah/blah work in a RS_TEXTURE node? Is that the idea in future? I'm fairly sure I read some blurb about it that said for karma.

USD is the native Scene file format for the Karma or Renderman Renderer. The question is will Redshift, Arnold, Octane, Vray.... change there native format to USD or not. I would say in the long run the current old Rendering process will go away just because no Renderengine Company will invest to update all there custom plugins for each DCC Software when they can have just one Plugin for all.

every layer of functionality gives more options but also more complexity. it is never easy to change the pipeline but in the long run it will be beneficial.

I build all my scenes at the OBJ level, then add a LOP Network, in the LOP node I import the scene, add a Karma node, then I am set, pretty straightforward IMHO, I don't see why some people seem to freak out about Solaris when it is so simple to use!

mandrake0
USD is the native Scene file format for the Karma or Renderman Renderer. The question is will Redshift, Arnold, Octane, Vray.... change there native format to USD or not. I would say in the long run the current old Rendering process will go away just because no Renderengine Company will invest to update all there custom plugins for each DCC Software when they can have just one Plugin for all.

every layer of functionality gives more options but also more complexity. it is never easy to change the pipeline but in the long run it will be beneficial.

USD is the native format only for Karma, in terms of Scene Description and geometric format.
It is not the native format of Renderman. Renderman is using Hydra delegate to translate USD stage into
it's scene description, and translating the geometry also into the native geo renderman can eat.
It has no USD procedural with direct translation either.

No other engine apart from Karma will be a fully native one in both scene description and geometry format.
You will get more of them supplying a procedural, so you can bypass the need to use hydra to do the translating.


L

mandrake0
USD is the native Scene file format for the Karma or Renderman Renderer.

Strictly speaking Karma and RenderMan are interfacing with Hydra, not USD. Hydra is doing the translating. For the case where e.g Redshift is running directly in obj context, a custom Houdini plugin created by the Redshift devs is doing the translating. Nothing can magically get from A to B - there's always a translator

Well. Solaris is getting more and more comfortable to use.
Probably close to be new /obj context - using SOP create nodes for details.

Solaris is better organized for rendering and object management than old /obj context.

But I found that redshift integration in Solaris is weak. So it's the problem - either RS will develop, or Karma (still not mature renderer).