Hello! I am a student working on a short film at my university. We are rendering our film in Renderman, using Husk to send jobs to our farm.
We've run into issues with some of our shots which include large-scale fx and a few shots over 100 frames in length. Is there a way to reference geometry sequences within a USD file on disk, without having the whole sequence (multiple frames of data) flattened into one single file?
For example, when exporting VDB assets into USD, a single USD file is created which references a sequence of separate .vdb files.
We want to do the same with geometry caches. Specifically, we have a big hair groom that comes out around 200 GB in size when all of its 100+ frames are flattened into a single .usd file. This huge file size puts a big strain on our farm server, which seems unnecessary when only around 1.5GB of data is needed for each frame.
I have messed around with the geometry sequence node, but that node is basically just a sopimport referencing a file node inside of an obj context. That means there's no way to make a USD saved to disk that references a sequence of separate .usd or .bgeo.sc files.
I've also tried the usdstitch rop, but that too seems just to take all the files given it and flatten them into a single file, instead of referencing the individual files.
Because it's possible to use a usd_rop to render a geometry sequence to disk with each frame cached as a separate file, I assume there's an easy way to reference that data within a USD file on disk - but I haven't been able to find it yet. Does anyone know how to do this?
Thank you!!
Writing USD to disk that references a geometry sequence
4886 8 6- zmw42
- Member
- 2 posts
- Joined: March 2021
- Offline
- mzigaib
- Member
- 976 posts
- Joined: April 2008
- Offline
zmw42
I've also tried the usdstitch rop, but that too seems just to take all the files given it and flatten them into a single file, instead of referencing the individual files.
If you use "$F4" it should save a sequence of UDSs instead of a single one you just need to remember to enable "flush data after each frame" to not have memory issues.
As far as I know except for VDBs when you are saving imported geometry from SOPs as USDs to disk it is going to save this first import layer as a native USD geometry in order to reference it later you can't reference bgeos directly as a layer which would not make sense as far as I am aware.
- mtucker
- Staff
- 4523 posts
- Joined: July 2005
- Offline
- AhmedHindy
- Member
- 136 posts
- Joined: Oct. 2020
- Offline
- goldleaf
- Staff
- 4199 posts
- Joined: Sept. 2007
- Offline
- zmw42
- Member
- 2 posts
- Joined: March 2021
- Offline
- protean
- Member
- 72 posts
- Joined: July 2006
- Offline
Hi,
I've stumbled upon this thread and looked into the example. There's an issue with the geo path in the swirl_mesh_topology usd in that it is a full path. In the swirl_mesh.usda they are relative. Is this by design? I have to manually/post process this usda to have a relative path to work cross platform at the moment. Well, when I say 'work', it works OK but there will be problems if the metadata is required.
Cheers,
J
I've stumbled upon this thread and looked into the example. There's an issue with the geo path in the swirl_mesh_topology usd in that it is a full path. In the swirl_mesh.usda they are relative. Is this by design? I have to manually/post process this usda to have a relative path to work cross platform at the moment. Well, when I say 'work', it works OK but there will be problems if the metadata is required.
Cheers,
J
Edited by protean - Nov. 16, 2023 10:14:22
john @ hydrastudios
- jsmack
- Member
- 8041 posts
- Joined: Sept. 2011
- Offline
protean
Hi,
I've stumbled upon this thread and looked into the example. There's an issue with the geo path in the swirl_mesh_topology usd in that it is a full path. In the swirl_mesh.usda they are relative. Is this by design? I have to manually/post process this usda to have a relative path to work cross platform at the moment. Well, when I say 'work', it works OK but there will be problems if the metadata is required.
Cheers,
J
The usd rop has an output processor to convert paths to relative paths. They appear as absolute paths when working interactively since the output processor hasn't run yet.
- tallen
- Member
- 16 posts
- Joined: July 2005
- Offline
I haven't found a better method yet, but I did find that saving as .bego.sc including adding the frame counter (usdconfigure) as mentioned in the .hip examples provided (thank you!), it still runs out of ram for large animated sequences of geometry. No savings there.
So in the rop geometry node, instead of saving as .bgeo.sc, I replaced it with the USD Export node, making sure to toggle on the "Flush Data After Each Frame" param. That's where I got my ram savings. Slower sure, and larger file size as mentioned here and in other forums, but at least negotiable for a farm. (be sure to up the links and paths to the usd nodes not the .begeo.sc
So in the rop geometry node, instead of saving as .bgeo.sc, I replaced it with the USD Export node, making sure to toggle on the "Flush Data After Each Frame" param. That's where I got my ram savings. Slower sure, and larger file size as mentioned here and in other forums, but at least negotiable for a farm. (be sure to up the links and paths to the usd nodes not the .begeo.sc
-
- Quick Links