What's the point in usd exporting?

[Zigmund]

First off, please excuse me for a silly question. I'm trying to understand how solaris and lops work.

As I understand, the idea of usd format is to use it in production pipeline more effectively and each department can work simultaneously.. Or something like that, I don't know to be honest.

However, as i'm a solo artist, i don't need those pipeline features and everything i need i do directly in houdini.

So what is the point of exporting scene assembled in Lops to usd? Also, I usually cache all simulations, animations and everything directly in Sops (in bgeo format), why should i cache it again on the disk in usd format? As I understand, having time dependent Lops network is not good, so for heavy scenes we need to cache it on disk and then evaluate it as frame range and so on.. 

But why? What are the benefits of all this approach? I don't care much about faster viewport, i just solo or hide necessary object during the work. Does it render faster?

Why importing from SOPs and rendering it without exporting to usd, is not better approach?

Or do i miss something? Sorry for a being emotional, as i said, I'm just trying to understand why I need to do things in certain way....

[Atom]

Funny you should ask. SideFX just released a tutorial on that topic.

https://www.sidefx.com/tutorials/lops-for-solo-artists/

[Zigmund]

51 minutes ago, Atom said:

Funny you should ask. SideFX just released a tutorial on that topic.

https://www.sidefx.com/tutorials/lops-for-solo-artists/

Actually, my question arises from this very video:)))) I mean, the tutorial shows how to do the things properly, but I didn't get why should I do it... He tries to eliminate all time dependancies through caching to disk in Lops... but I already cached everything in Sops. so why do I need to cache it again to usd? Due to time dependency that cooks some variables every frame? I just tried to do most of the things shown in the video. But I didn't see any benefit of it. Moreover, some branches took too much time to cache (I mean simple cache, not caching to disk).. I will rewatch it again, maybe i missed something.. 

[tamagochy]

First of all Karma works with USD only, so first saved render USD and than render. Second, USD can have materials and lights inside so you can open file and get same look. Also, if you want use render licenses you need to render USD. The same was with mantra it save to IFD and then render.

[Zigmund]

1 hour ago, tamagochy said:

First of all Karma works with USD only, so first saved render USD and than render. Second, USD can have materials and lights inside so you can open file and get same look. Also, if you want use render licenses you need to render USD. The same was with mantra it save to IFD and then render.

I'm not sure what do you mean by saying Karma works with USD only and I have to render to USD first. I just import everything to LOPs and after adding materials, lights, I would render without saving scene to USD. Or do you mean, Karma still does it under the hood?

I also decided to test one scene which is a bit heavy for my pc, so first i rendered it directly, without exporting to usd and then tried to make all those steps mentioned in the tutorial above, like caching animations and whole scene to usd and then render it. The only difference is that viewport was more responsive with "USD" approach. The render time was the same, so I'm still not sure, why I have to save everything to USD...

[Mike_A]

You don't have to cache / export everything to USD before rendering - if simply setting the scene up, adding lights and materials, and hitting 'render' works for you, that's OK.

Fundamentally Solaris and Karma are designed around larger productions - where caching / exporting to USD means larger scene data can be managed and handled more efficiently. If you don't need that, that's fine.  Karma uses USD as it's 'scene description' format -  so as you are assembling your scene (stage) in Solaris that USD 'scene description' is being constructed, and is used to create the image when you hit 'render'.

As you've noticed, caching / exporting to USD and bringing that data back into Solaris is simply an efficient way of storing parts of a 'render ready scene' in an efficient format. That means better viewport performance when handing larger or 'time dependent' scenes, and offers a way to store and recall that data for re-use, without requiring Karma to rebuild the same data over and over. If you don't need to do that, that's fine - just build the scene and hit render.

Edited March 19 by Mike_A

[tamagochy]

20 hours ago, Zigmund said:

I'm not sure what do you mean by saying Karma works with USD only and I have to render to USD first. I just import everything to LOPs and after adding materials, lights, I would render without saving scene to USD. Or do you mean, Karma still does it under the hood?

I also decided to test one scene which is a bit heavy for my pc, so first i rendered it directly, without exporting to usd and then tried to make all those steps mentioned in the tutorial above, like caching animations and whole scene to usd and then render it. The only difference is that viewport was more responsive with "USD" approach. The render time was the same, so I'm still not sure, why I have to save everything to USD...

Yes Karma save render.usd to the temp when you hit render and render it. If you have only one workstation it doesnt matter how you render, but if you want to use few machines for render you want to use render licenses not a full FX in this case you have to save usd and render it. Saving usd use full FX license, rendering usd use render license

Edited March 18 by tamagochy

[Zigmund]

hmm.. I think i got it.. I will try to follow "USD" approach in future projects, when applicable, for the sake of getting all benefits of Solaris, yet without trying to export whole scene to a final usd.

Thanks guys for helping me understand it.

[paranoidx]

‌There are things I’d love to use Solaris and the USD workflow for:‌

• ‌Multi-shot workflows‌ – Streamlining processes across multiple sequences.
• ‌Collaboration‌ – Of course, the incoming file package has to setup nice and tidy. I once received Maya animation files from other sources, and my goodness, it felt like burning in hell while trying to schedule the next steps!
• ‌File storage reduction‌ – I want to save assets in a more efficient way.

Not an expert—just keeping it simple, but I love it the way it is. Not a fan of time-dependent or destruction assets, though.