Hi,
i'm currently trying to migrate on Solaris/usd.
I want to talk about crowd workflow.

My agent setup is basic, but I wanted to try with a model with several cloths/hair/props to randomize them later with Crowd Assign Layer.


Then I cached the agent definition to disk before I ran the simulation.
And finally cached the simulation.



For now, I have 2 major problems :

1) Solaris Viewport Building Scene Performance
When switching from /obj/ context to /stage/, i'm using a sopimport node (or a sopcrowdimport) with the "Create Instanced SkelRoots" (default)

The viewport Houdini GL shows the full geometries of each agent (which are pretty high, because of hair cards, cloths, etc). When I have 10 agents, it's ok, everything shows up pretty fast and I can play animation.

But when I increase the number of agents, solaris becomes extremely slow, trying to show every geometry...
(mov in attachment)

It's the building scene (with all agents) that takes time.


Questions :
1a) Is there a way to configure a proxy system in Solaris for each agent to be able to switch between high/proxy/bounding box / or just show single part of each mesh ?


The DrawMode is only available on the Sop Import node, and not for each agent.
What is the workflow to create different preview mode so that I can switch from one to the other ?

1b) Should I cache 3 crowd simulations with different agent proxies ?
Should I cache the crowd simulation with all the High, Low, BoundingBoxes in the same sim, and then layer_configure the display in Solaris ?



2)Solaris Rendering Karma / Arnold
I'm using Arnold HtoA 6.1.4.3 (arnold 7.1.4.3) on Houdini 19.5.493. When I convert crowd sim to LOPs I'm not sure that instances are kept.
When I try to render 10.000 agents, Ram is going crazy, and then just crash. Just as if I had baked all my geometries... Even with Karma, ram is to high for rendering.
That's not viable, because I need to generate a full stadium which represents more than 10k agents.
When I render the crowd with Mantra in /obj/ context, 10k agents with my model costs less than 35GB ram. When I switch to solaris, it goes over 100GB.

Questions:
2a) Is there something to do to have better performances with agents rendering ?

2b) In the construction of the scene, is it better to split the crowd system in multiple parts (like multiple square of 1000 agents ?)

2c) Is my model too high for crowd ?



3) MANTRA vs KARMA for crowd ?
So, just to illustrate the difference as mentioned before between /obj/+mantra and /stage/+karma (and not arnold), here are ram usage :
/obj/+Mantra : loading very fast ~35GB ram


/stage/+Karma : very long loading time ~90-100 GB ram



3a) So my question is : Is it viable to render massive crowd with Karma & solaris at this time ? or I am stuck with mantra in /obj/ context ?


If someone have any advice or tips about that... because videos and other topics don't show examples with massive crowds.

Thanks !

hi,

A little less than a year ago we did a show with crowds in Houdini and Karma - https://vimeo.com/771064771 [vimeo.com]


For solaris viewport performance while building your agents you can mark the shapes with a USD purpose (render, proxy). So you could make a low res version of your agent or a bounding box for viewport purposes. There was an annoying bug regarding solaris viewport and crowdagents, as low resolution mesh shapes disappeared as you tumble around the viewport so we ended up using the skeletons (curves) as our proxy shapes. The playback performance of the agents in solaris viewport would be slower than in SOPs. For one thing the skinning was not done on GPU in solaris.

We had a one static USD crowd layer for each stadium and different animation layers that the artists could use depending on what phase of the match a shot was.

Regarding the rendering - in USD the instancing was ignored beneath skelRoot prims. The instancing benefited only the scene graph side of things. So all of the agents would end up unique and needed to fit in RAM.
We used distance LOD-s and preFrame scripts to cull the not visible agents.

The caches were very small and USD layering nature was a huge benefit to execute smaller shot specific overrides.

Hi, Thanks for your answer !

Very nice breakdown though, good source of inspiration and great work. The quality of the crowd is what i'm looking for.

spektra
For solaris viewport performance while building your agents you can mark the shapes with a USD purpose (render, proxy).

Ok, I wanted to be sure about the workflow for that :
I was thinking of adding proxies and boxes on each agents, and maybe save 3 crowd simulations (1 HD + 1 PolyReduced + 1 Box or skeletons)
Then loading this and setup proxy mode with a "Configure Primitive" on the crowd.
Do you think it's the best way to do it ?
Or is there a better option inside LOPs ?

spektra
Regarding the rendering - in USD the instancing was ignored beneath skelRoot prims. The instancing benefited only the scene graph side of things. So all of the agents would end up unique and needed to fit in RAM.
We used distance LOD-s and preFrame scripts to cull the not visible agents

Ok so I'll manage to have a crowd setup with small aeras with LODs, static instances and mix them up according to what is shown in the camera.

Thanks for the tips, and I'm always open to new ideas or maybe other experiences on Solaris crowds.
We use arnold as render engine, so is anybody have advices and optimization, thanks !

c0y
Ok, I wanted to be sure about the workflow for that :
I was thinking of adding proxies and boxes on each agents, and maybe save 3 crowd simulations (1 HD + 1 PolyReduced + 1 Box or skeletons)
Then loading this and setup proxy mode with a "Configure Primitive" on the crowd.
Do you think it's the best way to do it ?
Or is there a better option inside LOPs ?

The same crowd agent can have shapes with different purpose set up in SOPs. You can create a usdpurpose primitive string SOP attribute to control the purpose of the corresponding USD prim. The value should be either default, render, proxy, or guide. As you bring the agent to Solaris, the shapes with the value of "proxy" get displayd in the viewport while the ones marked "render" are rendered.

spektra
The same crowd agent can have shapes with different purpose set up in SOPs. You can create a usdpurpose primitive string SOP attribute to control the purpose of the corresponding USD prim. The value should be either default, render, proxy, or guide. As you bring the agent to Solaris, the shapes with the value of "proxy" get displayd in the viewport while the ones marked "render" are rendered.

I'm sorry to ask, but do you have an example (hipfile or screenshots) because I can't figure out how to add the proxy shape to the agent definition. Because my agent is composed by several shapes (body/hair/cloth).
Or maybe I'm not creating my agent the good way.

Basically, I created my agent crowd with all props stacked on top of each other, and after the crowd_source, I'm using Assign Layer to make variations.

So I don't know where to put my polyreduce and this usdpurpose string attribute so that it's available in Solaris.

Here is an example of my agent definition when imported in Solaris :



Thank you so much !

you can add any kind of proxy shape to any layer in your agent.

in Solaris just make sure to turn off the "Shade open curves" if you are using curves.

Thank you so much for your help. I'll keep digging all that stuff ! But thank you for the tips, it helps a lot !