Workflow question: Activating RBD objects over time

[asnowcappedromance]

hey guys,

I'm dealing with a large-scale destruction scene right now and I'm activating pre-fractured objects over time.

The way I'm doing it right now: I have two groups, the inactive group which gets fed into a static object in DOPs

(group gets updated each frame so "Use deforming geometry" is checked) and the active group which is fed into a

RBD fractured object ("creation frame" is set to $F in order to create objects as soon they get activated, those

objects are being deleted in SOPs one frame after they get created in order to spawn every object only once in DOPs)

So this workflow works pretty well, but I'm wondering if spawning every object on the first simulation frame and then

only changing the "active value" of each object is a more robust / faster solution.

What are your experiences on this?

thanks,

Manu

[Ryan]

That setup sounds pretty good. In my experience, starting every object on the first frame is pretty slow and hard to keep up with. Doing as much work in SOPs is always better.

One quick tip that could speed things up,

In the RBD Solver if you uncheck 'Make Objects Mutual Affectors', the pieces will not collide with each other. So then you can set up some custom affectors using the AffectorDOP if you create some groups. So if you don't need the sim to be 100% accurate, you can reduce some of the calculation.

[ford77]

I don`t completely understand the setup you described and I don`t have houdini open right now,

but I did something like this not long ago.

Using deforming geometry slows everything down, because sdf collision

representation needs to be calculated from frame to frame. it`s probably

easier to create the collision sdfs on the first frame and activate

the objects during the simulation.

I created a point for each fracture object in SOP with a value I can use for activation in DOPs.

I used distance from a certain point - a circles center. I added this attribute to the

RBD objects as a user data and turned of "create active objects" on the RBD fracture object.

Then I animated the circle`s scale and in the DOP I activated the objects with

the "active value" node with an expression what compared the user data

- the distance - from the current RBD object and the circles current scale.

if the scale was bigger the fracture object activated.

Basically, you can create any custom attributes in SOP context, add it as custom data

to your fracture objects and activate or deactivate them with a simple expresseion

in the active value node using the custom data value.

edit: this is one of the tests:

http://vimeo.com/34746351

there are no collision objects or forces what cause the fracture. Each object has an initial velocity

a little randomized, and I use an animated circle to activate the objects.

Edited January 16, 2012 by ford77

[GallenWolf]

One reason to have all of them spawn on the first frame, is that you can have the active dop objects collide against the inactive.

GW

[krot]

One reason to have all of them spawn on the first frame, is that you can have the active dop objects collide against the inactive.

GW

what if fracture geometry is animated (e.g. rotation at geo level). is there any way to transfer proper velocity to newly activated piece?

Edited February 2, 2012 by krot

[hatrick]

hey ford,

your solution sounds pretty solid. Do you have an examplefile showing the setup.

Would be great.

Thank you

HT

[ford77]

I made this simple template scene with sticky nodes.

I hope this helps. Let me know guys if anybody has a better

solution.

RBD activation based on distance.hip

[Netvudu]

Hi ford.

I´m doing pretty much the very same setup but assigning groups in DOPs and then calling the custom data with a dopfield. Also, your method for checking the distance is very nice and saves nodes, but it requires more complex expressions. I just use a simple Attribute transfer from the "activator" geometry. But it´s basically the very same thing.

It is a nice way to make it work, but (as SESI knows through beta forums) I´m not too happy with that. It requires 10 to 15 nodes for something that should be much faster. Also having to use a ForEach is certainly slowing up the cooking, which might be important for simulations with many pieces.

I guess we need some sort of Attribute Transfer DOP which works per dobject or make the Group DOP node admit a deforming bounding object, much in the way we do it for POPs, that would save most of this setup.

Edited February 3, 2012 by Netvudu

[krot]

Optional, you can cook ForEach only once to let it compute centroids of your pieces and store them in an attribute. so it will be available in dop object's geometry and this will allow to calculate "activation distance" right in dops.

although it is suitable only if there is no animation at sop level

[asnowcappedromance]

hi guys!

thanks for all the input, I actually didn't realize people were after all replying to this thread, that's why I didn't see it.

First of all, Ford, you're totally right that "using deforming geometry" cooks the collision geometry every frame,

but that doesn't affect me anymore as I switched to the Bullet Solver who doesn't care about sdf's.

I actually know all of the above described techniques, I use a similar approach with a pointcloud lookup to activate my dop objects now,

but yes, I agree that there should be a way in DOPs to easily look up attributes that were created in SOPs, so far I always created

a new empty data set and modified it with either a dopfield() or point() expression to look up the values.

@Ryan, thanks for the tip, I might actually do that, totally forgot about the Affector DOP, I hardly never use it although it can be quite handy at times!

cheers,

Manu

[hatrick]

thank you ford !