Hello,

do you know how to delete some primitives of deforming collision geometry at a specific frame?

I created some spheres crushing into a stack of coins. At some frame they are hindering, so I have to delete them. At first I thaught just deleting them in the bulletsolver's upstream would do the job, but the solver just keeps them in place from that frame forward. Also I tried a popkill node wired to postsolve inside the solver's forces. It was intended to select the colliders via a point group, but didn't work neither.

Do you have an idea how to solve this?

Maybe try to use collisionignore [www.sidefx.com] attribute.

vicvvsh
Maybe try to use collisionignore [www.sidefx.com] attribute.

thanks, that sounds appropriate.

I haven't dived inside the bulletsolver before, do you you know how it works there?
Probably I have to add that attribute to rbdbulletsolver1/dopnet/collision_object. Right inside RBD Packed Object's interface I don't see a parameter for collisionignore so I tried wiring a popwrangle behind it. But I still don't find the attributes I type in there in the resulting geometry.

Is there another way I have to deal with this?

EDIT: Now I have figured rbdconfigure also has a parameter for collisionignore. I don't know yet how to animate the string correctly, so my workaround was using that node twice and wire a switch behind them. But the bulletsolver doesn't seem to update that attribute. Also adding deforming or animated does not help here. So I guess I can't solve this from outside bulletsolver.

Here a simple scene where animated collisionignore attribute in rbdconfigure1 sop. Collision Ignore checkbox is on from 1 to 120 frame, then it is off. A value of this attribute is name of dop object - groundplane inside rbdbulletsolver.

vicvvsh
Here a simple scene where animated collisionignore attribute in rbdconfigure1 sop. Collision Ignore checkbox is on from 1 to 120 frame, then it is off. A value of this attribute is name of dop object - groundplane inside rbdbulletsolver.

Thanks, I'm glad to see, the attribute animation is considered in the bulletsolver.

Still there might be the same problem in your file as in mine. The spheres that are created after collisionignore was added behave as expected. But the older spheres don't have that attribute value, so they keep lying on the ground.
Do you know any way to edit the attribute afterwards?

EDIT: Finally I found a solution: I discovered the bulletsolver uses a switch node to switch from the collision object to none. By animating that switch I was able to specify which object actually appears in the solver. Level 3 was to switch to the second collision object in my scene. I had to adjust the creation frame in the second rbdpackedobject to the first frame it is taken in account from the solver.

Сollisionignore is just a string attribute on a point (packed primitive) and you can manipulate with value of this attribute during simulation. Double click on rbdbulletsolver node and use any POP dop node to build a logic you want to control behavior of rbd simulation.

vicvvsh
Сollisionignore is just a string attribute on a point (packed primitive) and you can manipulate with value of this attribute during simulation. Double click on rbdbulletsolver node and use any POP dop node to build a logic you want to control behavior of rbd simulation.

Thanks, this is a more easy way than I found.
Actually I tried this before. I guess it didn't work because by habit I used $F instead of @Frame. So in future I won't use those HScript expressions in VEX as they don't always work.

freewind
. So in future I won't use those HScript expressions in VEX as they don't always work.

The reason why something like $F wouldn't work for you is that variables or hscript expressions in wrangle code are evaluated just on the first frame to generate the vex code which is then compiled

So while they can be used to help generate vex code, any animation would be ignored, as changing vex code and recompiling every frame would be an extreme performance hit

tamte
So while they can be used to help generate vex code, any animation would be ignored, as changing vex code and recompiling every frame would be an extreme performance hit

Thank you very much, I'll consider that.

vicvvsh
Сollisionignore is just a string attribute on a point (packed primitive) and you can manipulate with value of this attribute during simulation. Double click on rbdbulletsolver node and use any POP dop node to build a logic you want to control behavior of rbd simulation.

Hey there, unfortunately I still haven't found out how to apply this to some custom collision object.
I slightly adjusted your file with my own groundplane and imported that to the solver. But I haven't found a way to set its name to be detected by @collisionignore. On the documentation you gave me the link for I read about collisiongroup, so I thaught that would do the job, as I can simply set in rbdconfigure. But it doesn't work like that.

I figured the groundplane node inside bulletsolver has an Object Name parameter. This sets the attribute I need, it is taken in account by collisionignore. Now the rbdpackedobject node that defines collision objects also has an Object Name parameter. But there it does not work for some strange reason.

Do you know another way to set the DOP object name?

Try it. Attributes s@collisionignore, s@collisiongroup and conditions should be for both an active and static objects.

Thanks, treating them all as simulation objects instead of collision objects seems to work better. I will try that.

I poked around in the RBD Bullet Solver a bit. All geometry connected to first input of the solver (Geometry) has dop name "rbd_object" and connected to forth input (Collision Geometry) has dop name "collision_object". They and "groundplane" predefined in a RBD Configure sop in multiple selection menu of Collision Ignore parameter and in the others parameters. You can choose on of these name in that menu. Example attached.

Thanks well I have to switch from one collision object to the other, so I guess I'll have to adjust the usual way somewhere. Probably the default dop names won't work in this case.

This can be accomplished a number of ways.


Using a Collision Ignore attribute:

This method will give you the greatest flexibility as it will allow some RBD pieces to continue colliding with the collision geo while allowing others to simply ignore the colliders you want.

The rbd geometry feeding into RBD Bullet Solver either through its first or third (proxy) input is named "rbd_object", while the collision geometry feeding into the fourth input is named "collision_object", and the groundplane or heightfield collider is called "groundplane". These are the object names you can use in the collision ignore field. You can add collision groups if you want to target subsets of these if need be.

The collision ignore field must be bilateral - meaning the various objects need to be ignoring one another. So rbd pieces ignoring "collision_object" will need the collision geo to be ignoring "rbd_object".

If you need to update the collisionignore attribute dynamically from SOPs, you can add it to the list of attributes in
Properties > Pieces > Override Attributes > Attributes for RBD objects
or
Collision > Collision Geometry > Override Attributes > Attributes for Collision geometry.

Emitted RBD geometry will not be updated from SOPs - you will need to handle updating the attributes yourself. Dive inside the RBD Bullet Solver SOP and use a geometry wrangle, or a SOP solver, or any other way of modifying the RBD pieces' attributes as needed.



Updating the Collision Geometry's geometry representation:

Set the bullet_georep attribute on the pieces you want to no longer collide with anything to "none" and add that attribute name to the Collision > Collision Geometry > Override Attributes > Attributes list to update it dynamically from SOPs.




Delete the Collision Geometry dynamically:

By feeding the collision geometry into the same input as your other rbd pieces (make sure there are no name clashes) they will be treated as regular rbd pieces you can now access by diving inside the RBD Bullet Solver.

In order for it not to become active by default, make sure you configure it properly by setting its active, animated and/or deforming attributes as needed.

Dive inside the RBD Bullet Solver and add a SOP Solver. From there you can simply delete the pieces you no longer want to be participating in the simulation.

Make sure to delete the remaining collision geometry from the various outputs (1 and/or 3) of the RBD Bullet Solver SOP if you do not want it to be cached out with the rbd pieces.




More advanced colliders:

Having said all that, if you need to update the collision geometry's attributes dynamically based on what is happening in the sim, as opposed to doing it in SOPs blindly, you will want to treat the collision geometry as regular rbd geo in order to have access to it when diving inside the RBD Bullet Solver.

The reason there is a fourth input to the RBD Bullet Solver node for collision geometry is to make it easier and faster to setup collisions with geometry globally, which you don't care to output or do anything too fancy with during the sim. For example, using the set environment for collisions, or an animated character to smash whatever it is you need breaking etc...
If you need to do more than simple collisions that can be static/animated/deforming etc, you may need to treat them as regular RBDs and feed everything into the first input of the node, making sure you configure all the various pieces and colliders appropriately using the attributes the bullet solver recognizes.
The RBD Configure SOP exposes all these attributes in a convenient way.

Thank you very much for your detailed explanations.

I've fed it all in the first input now, I'm glad that finally works.

Thanks to you in my next project I might do more advanced techniques.