Hi

What would be best approach for RBD simulations in Solaris?

We all saw tutorial from Applied Houdini in which Steven is fracturing bottle on the shelf. But doing actual production case means thousands, or 100k rigid body pieces.

Approach that we established is to import static geo of objects with SOP import. (not as packed primitives, but as regular geometry). So in Solaris we get same path structure as LDEV asset.

Then using point transform node pieces are moved around with point cloud (same thing that trnsfrom pieces does, but in LOPS)

And then we sublayer all of that against LDEV asset, so all shaders get reassigned to RBDs.

Then we can write it out to USD.

Only problem is that writting out of that USD takes 4-5 hours for 100+k rigid body pieces. Actual sim for that was shorter than writing of USD.

It seems that point transform node is very slow. Tried doing it in SOP modify. It is even worse and often times it would crash. Only solution left is to try to do it in wrangle. But seems like Solaris chokes on manipulating thousands of objects at once.

Other approach would be to load geo point instancer and then maniuplate instance points. Still have to test speed of that. And also, how that would work with sublayering LDEV work on top of that?

Hey,
instead of using the pointinstance node , I found it mutch faster to only cache out the transforms per pieces as a overlay. Then over it to the static highres geo.

Check out the rbd_destruction lop node. It has a few ways how you can treat rbd sims in solaris. Also the mentioned transforms overlay method.

Also lowres proxys for the viewport did help a lot for fast er feedback.

I found solaris pretty slow with updating 10.000s of prims...caching the geo as one big mesh is mutch faster.
Maybe consider saving some parts of the geo/sim as one mesh with a few subsets

I'm very curious about the proper way to set up instanced rbd debris in Solaris. Anything I tried was 3 and more times heavier on disk than bgeo point cloud + copy to points of packed.

I did some tests regarding topic, here are the results:


1. Load packed usd with sop import as point instancer. Viewport really struggles with this one. It tries to draw and redraw, like it goes to some kind of loop.
2. Load static usd with sop import, then transform points with pointxform node. Viewport sometimes gets stupid with this, but better than first approach.
3. Load static usd with sop import, and load just transforms with other sop import. This solution worked the best, viewport also behaves ok. Of course it is not like sops, it takes 10-30s to refresh. But that is best we can get for now I guess.

Good news is that this will be solved in future releases.

In meantime I remembered one technique that we used on past project.
We did scene which needed tens of thousands of centipedes and worms crawling around. I inherited scene with 15TB of caches. Someone was caching path deforms on tens of thousands of worms.
My approach was to put path deform inside displacement shader. I would just load centipedes that are in place and then displacement shader would read out appropriate curves and deform them into place. It worked BLAZINGLY FAST in Karma. Like 20x faster displacement load time than in mantra.

So, last night lightning came up to me. Why don't do RBDs in same manner. Here's the result:




Shader is binding attribute with center of piece, id, and based on that gets attributes from rbd point cloud. Initialization takes only couple of seconds. And best thing, this can be one primitive in Solaris, so scene will be very light.

This is "workaround", of course, but interesting idea and concept of solving things.

Just keep in mind that "xyzdist", "getattribute", "primuv" can be used in shader. That is the best thing about Mantra/Karma.

This definitely fits the think outside the box category, thank you for sharing this.

For main RBD sims, technique described on CGWiki works for me.
https://www.tokeru.com/cgwiki/HoudiniLops#Note_for_v19+_users [www.tokeru.com]

Thank you,but how should i do to create this "displacement" in materialX?

patience
Thank you,but how should i do to create this "displacement" in materialX?

In materialx don't know. Last time I tried, couldn't figure out how to do proper 3d world space vector displacement in materialx.

Aniway, in meantime adopted system from Luca (USD survival guide):
https://github.com/LucaScheller/VFX-UsdSurvivalGuide [github.com]

It works very good.

In H20 there's RBD procedural, that hopefully solves all of our problems with rbd.

With H20, is there any reasonable way to get an RBD Sim into Solaris which does not involve simming it with the RBD destruction LOP? I am still struggling with that.

Also kind of struggling with this. I can't seem to follow a concrete example that demonstrates a sop > export geo > solaris workflow that has a similar workflow to transformpieces sop. I've been to get Matt Estela's setup to work: https://tokeru.com/cgwiki/HoudiniLops.html#rbd_to_lops_as_a_point_instancer [tokeru.com]

Edit: I have successfully gotten Matt Estela's example work however the performance is very very slow in viewport with a production-level amount of rbds.

So I tried exporting just the transforms set to "overlay transforms" on the usd export sop, and the performance is better, however the disk size is basically the same as exporting out the geo, so no real saving there, although the performance is better in viewport.

jarjarshaq
Also kind of struggling with this. I can't seem to follow a concrete example that demonstrates a sop > export geo > solaris workflow that has a similar workflow to transformpieces sop. I've been to get Matt Estela's setup to work: https://tokeru.com/cgwiki/HoudiniLops.html#rbd_to_lops_as_a_point_instancer [tokeru.com]

Edit: I have successfully gotten Matt Estela's example work however the performance is very very slow in viewport with a production-level amount of rbds.

So I tried exporting just the transforms set to "overlay transforms" on the usd export sop, and the performance is better, however the disk size is basically the same as exporting out the geo, so no real saving there, although the performance is better in viewport.

Well that's exactly my problem. One would think, that the transform pieces workflow would be very well suited for a pretty similar usd workflow (I actually thought that the rbd destruction lop in h20 would be that), but it turns out it is not (or at least I don't know how). Going Matt's route is really slow when writing out the instancer usd. I also tried exporting the points to a seperate usd file, but loading points from sops which have a name attribute is also pretty slow because it would create a primitive per point. So renaming the name attribute to name_x and using that in the instancer does not work because the position would be off (probably because of a missing pivot which is a primvar now). But even ignoring that, the instancer is still way too slow on export. I hope this is something that can be adressed in 20.5 and is not something that Pixar/USD has to figure out first. Maybe someone from the sidefx team can shine some light on that topic.

Yeah I had some back and forth with sidefx on this a while ago; when I first wrote up that method it was fast, then it got slow with later builds. The 'correct' answer is to swap over to the rbd destruction lop.

I've not used it on a project, but diving inside it just now, the hda seems designed to be tweaked and hacked. I'd assume if you have enough time and are confident in your skills, it shouldn't be too much effort to port an existing setup over.

Rob Pieke explains some of the thinking, why other methods are slow, why the new workflow is as it is here:

https://youtu.be/R4SLw5EdzQ8?t=1319 [youtu.be]

It really depends on what it is you're trying to do. The RBD Destruction LOP is designed as a template for injesting data from the stage and destroying it, with special care taken to place everything back in the same hierarchy to minimise primvar and shader work after the sim - if you keep everything in the same hierarchy, primvars and shader bindings are inherited.
You don't have to do the sim in there however - object merge the geo coming out of the first input in the embedded editable subnet and fracture it in regular SOPs, sim it etc... You can then object merge that simmed geo back into the editable subnet and pipe into into the appropriate output node. You may want to object merge your simmed points too if you plan on using the procedural.
The reason you may want to import the geo from the RBD Destruction LOP is that is prepares the name for you to make it easier to track where each piece of geo originally came from. From there, any fracturing method you use which simply appends to the existing name attrib will work fine.


On the other hand, if you're adding new destruction elements to the stage, things can be a lot simpler since you don't have to be so careful with prim paths and their final destination.


A few things to keep in mind however performance-wise.

1. Point Instancers bring little to no benefit when adding fractured pieces. You end up creating just as many prototype prims as you have pieces and you may run into precision loss issues as PI transforms are authored as floats and not doubles. PIs only really come in handy when instancing debris for example.
   
   
2. Bringing in fractured pieces as unique prims - this has the advantage the transforms can be authored cheaply as transforms on the geometry's (parent) prim, saving on disk space requirements. However, having many thousands of prims on the stage in the same hierarchy will hurt the stage's performance. (transform blur)
   
   
3. Bringing in the fractured geometry as single prims with deforming points can minimise the impact on the stage, however disk space consumption will be negatively impacted. (deformation blur)
   
   
4. Bringing in the fractured geometry as single prims and using USDSkel to deform that geometry is one way of minimising disk space and impact on the stage, however it can be tricky creating these, bindings aren't trivial and vertex normals aren't currently supported.
   
   
5. Bringing in the fractured geometry as single prims and using a procedural to deform the pieces at render time is the most efficient way of handling large quantities of fractured RBDs, especially if reading the point caches off disk as bgeo caches.
   

For 1) there are several ways of doing this, including using the Transform by SOP Points LOP, or importing the pieces as static geo first and merging in their transforms.

Here's an example hip file with a few various examples of how to bring RBDs into LOPs.

In the next version of Houdini, the RBD Procedural LOP has been broken out into its own node, so you can use it without having to go through the RBD Destruction LOP.

Hi Nick, thanks a lot for all the info. So I tried 5 but what your examples did not show is how to make it work when the geometry is already prefractured (I need to construct it in this way to be able to only fracture a couple of objects and copy them for the simulation).

I think I am pretty close to a solution, but for some reason the procedural preview won't show any animation. Maybe you can take a look at the attached file of a simplified version of my setup to help me understand what I'm doing wrong.

Ok, seems I overthought it as I was under the impression that the incoming geo had to match the one coming out of the simulation - but it doesn't. The solution was weirdly simple (and exactly as you did it). Leaving the working version here in case anybody is interested.

As long as the name attribute is derived from an existing prim on the stage, that prim will be replaced by whatever geo you give it (or it'll have its geometry attribs muted and child mesh prims will be created underneath it when choosing the animated xforms option) - so as you have discovered, you can happily abuse that to replace any geo on the stage with whatever you want.

As for pushing back the sim onto existing pre-fractured geo on the stage, depending on how the prefractured geo lives on the stage, here are a couple of options.

Thanks a lot, this is all super helpful in understanding better how this works.

One thing I am seeing is that when I increase the timeline length in my production scene which has just around 20000 pieces to a length of around 350 frames, the rbd destruction lop is cooking for quite some time before it is ready to go (about 4 minutes). Once it has cooked its pretty fast to update to a new frame (which is probably just the preview procedural kicking in) and very quick to cache. I am wondering if this is to be expected or if there is something I am missing here.

It also seems, that loading just one static frame of the cached points and having the long framerange is taking the same amount of time.

Here's my attempt at using rbd procedural.

It works much better. I load bgeo pts cache directly in tool, it takes 5-10s to load.
Forgive me for bad rbd sim:
https://drive.google.com/file/d/1wCBnWBMhfFMRiT5fkBRLi1h9KoQWgc7G/view?usp=sharing [drive.google.com]

Previously we done this with skeleton rbd bindings from Luca Scheller.
https://drive.google.com/file/d/1JmMxLYsI9yX6z-Ol0yY5fDM0iLBKwv6I/view?usp=sharing [drive.google.com]

At some point I'll try this new rbd procedural on bigger scale. But for now it seems it doesn't have any problems with number of rbd pieces.

Htogrom
Here's my attempt at using rbd procedural.

It works much better. I load bgeo pts cache directly in tool, it takes 5-10s to load.
Forgive me for bad rbd sim:
https://drive.google.com/file/d/1wCBnWBMhfFMRiT5fkBRLi1h9KoQWgc7G/view?usp=sharing [drive.google.com]

Previously we done this with skeleton rbd bindings from Luca Scheller.
https://drive.google.com/file/d/1JmMxLYsI9yX6z-Ol0yY5fDM0iLBKwv6I/view?usp=sharing [drive.google.com]

At some point I'll try this new rbd procedural on bigger scale. But for now it seems it doesn't have any problems with number of rbd pieces.

hey @Htogrom! I've been working on a destruction shot and I have a lot of sims with thousands of points. I'm fairly new to solaris and karma. I know this might be too much to ask but if possible, can you please send me a hip file or something like that explaining how to setup and render heavy rbd sims in solaris?

gantisiddhartha444

Htogrom
Here's my attempt at using rbd procedural.

It works much better. I load bgeo pts cache directly in tool, it takes 5-10s to load.
Forgive me for bad rbd sim:
https://drive.google.com/file/d/1wCBnWBMhfFMRiT5fkBRLi1h9KoQWgc7G/view?usp=sharing [drive.google.com]

Previously we done this with skeleton rbd bindings from Luca Scheller.
https://drive.google.com/file/d/1JmMxLYsI9yX6z-Ol0yY5fDM0iLBKwv6I/view?usp=sharing [drive.google.com]

At some point I'll try this new rbd procedural on bigger scale. But for now it seems it doesn't have any problems with number of rbd pieces.

hey @Htogrom! I've been working on a destruction shot and I have a lot of sims with thousands of points. I'm fairly new to solaris and karma. I know this might be too much to ask but if possible, can you please send me a hip file or something like that explaining how to setup and render heavy rbd sims in solaris?

Here it is: