Search - User list
Full Version: Animated topology to USD without caching a huge file
Root » Solaris and Karma » Animated topology to USD without caching a huge file
abhassan81
Hi, I have a liquid sim that is saved as bgeo.sc sequence. I bring it in Solaris and I want to save the output to a USD file to be used for rendering with Karma. My goal is to get a single USD file, with its layers folders and files, not a USD sequence. I also want those files to be small with references to the bgeos. I don't want huge USDs with geometry saved in them.

Here's my struggle:
1- I load the bgeos as packed disk prims in SOPs - use sopcreate or sopimport to bring them in LOPs - set Topology Attrib to Animated and set the Layer Save Path.
Result: The resulting file when loaded shows all the frames together.

2- I load the bgeos as full geometry or packed disk sequence.
Result: The USD file for the layer gets so large, saving all the geometry in it.

3- I load the bgeos directly into LOPs using Sublayer file.
Result: The file shows the first frame only.

4- I do #1 but save a USD file sequence.
Result: The resulting file sequence is animated, but a file sequence is not desirable in this case.

What is the proper way to do this?

Using Houdini 18.5.351 on Windows 10. Here's a file showing the different tests. To see the results, please run each USD ROP.
Image Not Found


Thank you,
Ahmed
lewis_T
Why do you want it in a single file? The mesh is changing topology, so there is zero benefit to having one cache file.
The whole point of the USD per frame is to alleviate the overheads. I would output the per frame USD with point v, and
then use USD stitch clips to be a wrapper around the frame sequence.

Could you explain why you prefer/need a single file?
Regarding file sizes, have you tested them to compare?


Cheers

Lewis
jason_iversen
Hi,

You can set the payload to directly reference the BGEO file on disk. So, Solaris can read the BGEO file directly and so it may possible to load geometry like this without conversion to USD first. For more complex conversion/import from entities in BGEO, you must use the SOP Import LOP.

TBH, I haven't tested this workflow much yet myself, but it may help for some typical FX data.

Good luck,
Jason
abhassan81
Hi Lewis, Thanks for the reply.

Honestly, no reason other than it's easier to manage, pipeline speaking. It would seem like if you can write a single file with geo of the whole frame range, you can write a single file that references an animated cache as well. Also, I don't know if you can render a USD sequence with command line using husk, can you?

BTW I tried stitching a sequence, it gives the same result as writing a single one.

I'm trying to figure out the best workflow.

Thank you,
Ahmed
abhassan81
jason_iversen
Hi,

You can set the payload to directly reference the BGEO file on disk. So, Solaris can read the BGEO file directly and so it may possible to load geometry like this without conversion to USD first. For more complex conversion/import from entities in BGEO, you must use the SOP Import LOP.

TBH, I haven't tested this workflow much yet myself, but it may help for some typical FX data.

Good luck,
Jason

Hi Jason, I'm not trying to convert existing bgeo files, I want to reference them. My issue is with the output USD file used for rendering. If I can have that as a single file that references an animated cache, I'd be happy.

Thanks,
Ahmed
mtucker
Composition arcs (reference, sublayer, payload) cannot be animated.

The closest thing is value clips, but the source BGEO sequence needs to be explicitly run through the USD Stitch Clips ROP, which generates a USD file containing the “value clip” definition (a bunch of special metadata on a prim).
abhassan81
Thanks for the info mtucker. That's good to know. I'll try Stitch Clips.
AhmedHindy
stitch clips for deforming liquid sims generate a topology file that writes a huge .usda file that is not necessary since its a deforming polysoup mesh and not an animated one.

How do you efficiently load a sequence of deforming geo into Solaris without Husk converting them into .usd files in the $TEMP% folder? this slows down the time-to-first-pixel significantly and increases ram usage by alot
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB