solaris / karma working flow.

   1321   4   2
User Avatar
Member
7 posts
Joined: June 2019
Offline
Hello, I have started to move from RS / Mantra to Karma, as I found it really quick in viewport workflow and disk rendering also. 
Together with that, I start going into Solaris env, but I'm still not sure I get the correct workflow.

I read all around the project structure should be:
/obj
- all geo and sim 

/lops 
- import the above with scene import
- USD layout
- add lights, material, camera
- animate camera
- render.

SO, it comes to some issues for me.
First, once I place USD objects, I cannot see them back in /obj, so I cannot make an animate camera there...as I won't see all objects. But, animating a camera in /LOP, in a scene with forest or crowd, will move very slowly, waiting every frame to reload in the scene.
I guess it is from scene import. Should I cache all /obj first, with USD export from  /obj? It is not quite ok, because we all know how many interventions on geometry are made before rendering. All this will result in re-export the USD. 

So, which is the best workflow for a scene heavy on geometry, tons of assets imported as USD Lyres (from previously made lib. for this project), animated camera (about 2000frames/25fps,  VFX(smoke), some DOP net.

Thanks,

Above that, if USD objects are placed in LOP, how can I use them as collision objects in simulations which are in /obj?
Edited by tenoztz - Aug. 23, 2023 10:13:10
User Avatar
Staff
4502 posts
Joined: July 2005
Offline
A couple of choices here:
* You can create your camera in /obj if you find the playback responsiveness better there. If the geometry is animated, skipping the scene import will certainly speed things up. This is a good approach if you are also making lots of tweaks to your geometry while setting up the camera.
* If you geo is pretty much locked down, I'd suggest using the scene import and a USD ROP to save the animated geo to USD layers on disk. Then load those layers back from disk and work on your cameras/lights there. This should give you considerably better performance that working at the geo level because there will be no SOP/OBJ cooking as you move from frame to frame. But of course if you change your geo you have to re-cache it to disk.

To use USD data in simulations, you usually have to use the LOP Import SOP to bring the USD geometry into SOPs/DOPs. In most cases you'll further want to unpack the USD geometry to polygons, but in some cases you maybe be able to get away with using USD packed prims (I think USD packed prims can be used as collision objects without unpacking them).
User Avatar
Member
7 posts
Joined: June 2019
Offline
mtucker
A couple of choices here:
* You can create your camera in /obj if you find the playback responsiveness better there. If the geometry is animated, skipping the scene import will certainly speed things up. This is a good approach if you are also making lots of tweaks to your geometry while setting up the camera.
* If you geo is pretty much locked down, I'd suggest using the scene import and a USD ROP to save the animated geo to USD layers on disk. Then load those layers back from disk and work on your cameras/lights there. This should give you considerably better performance that working at the geo level because there will be no SOP/OBJ cooking as you move from frame to frame. But of course if you change your geo you have to re-cache it to disk.

To use USD data in simulations, you usually have to use the LOP Import SOP to bring the USD geometry into SOPs/DOPs. In most cases you'll further want to unpack the USD geometry to polygons, but in some cases, you maybe be able to get away with using USD packed prims (I think USD packed prims can be used as collision objects without unpacking them).

So, on a scene with crowd and a lot of scattered objects, I should do:
- /obj - build environment
- cache /obj as USD
- load the cache in /LOP
- use /layer to scatter props around
- cache USD props
- load USD props back in /obj and build crowd sim having loaded USD props as collision
- cache crowd result with export USD
- back in /LOP load cached crowd
- build lights and n=animated camera
render.
Looks messy to be honest.
Or I missed something. But if the above are the correct way, I cannot see the USD workaround useful as it complicated much more all the work.

Thanks
User Avatar
Staff
4502 posts
Joined: July 2005
Offline
Caching is only necessary/useful for those parts of the scene that are animated and cause expensive cooks every time you change frames. Assuming the environment is static, there's not much benefit to caching it to USD. For the scattered props, again, if they're static, no need to cache them. Your crowd maybe you would want to cache for better performance.

Also, using File Cache LOPs these caching steps becomes optional and occur right in the LOP network so if you make changes you can re-cache with the press of a button. Or if you aren't seeing any performance issues, don't cache them to disk. Also, I would not recommend the USD Export SOP unless your desire is to stay in SOPs (which it sounds like it is not). If you're going to be jumping to LOPs anyway, you're better off using the full suite of tools in LOPs (Scene Import or SOP Import feeding into a File Cache LOP).

TL;DR: If your interactions with your scene are too slow, cache the slow parts to make them fast.
User Avatar
Member
3 posts
Joined: Oct. 2021
Offline
At the moment I am still learning, I feel documentation and some tutorials are highlighting some features on solaris which are really helpful. But at the same time I still need to often go back to obj level to tweak things and I miss visual feedback, specially on lights and cameras, if these were created on state level... by default I am creating everything (light and camera) on obj level but not sure this is the way to go
  • Quick Links