Using the RBD Bullet Solver, I wanted to flip a truck-sized vehicle, by placing a ramp, affecting the right-side wheels
The goal was to have the vehicle land on it's side after a brief moment in the air, then sliding on the ground
I switch from animation to RBD simulation, just before the wheels would touch the ramp.
In one one tutorial I saw they used the pop force to move the vehicle.
So I used that.
If I wouldn't use the POP Force the vehicle wouldn't move at all.
But once the vehicle is in the air it gains speed, rather than slow down and flies way to far.
Assuming the POP Force is the culprit, even though it is only active shortly.
How do I make the jump shorter?
Can I make the switch from animation to simulation be triggered by the vehicle touching the ramp?
When using the POP Force to move the vehicle, it takes 1-2 frames for the vehicle to speed up, making it difficult to match the animation speed.
Then it apparently gained too much momentum already, and flies way too far through the air.
Do I use the trail SOP to calculate velocity, to be used in the RBD sim, to know the initial velocity, instead of the POP Force?
If so how would I implement this?
In an older video someone showed how to switch from animation to simulation in a Dopnet, using the SOP Solver and an attribute wrangle:
if (@Frame >21{
i@active=1;
i@animated=0;
}
But the internal structure of the RBD Bullet Solver is much more complex and I didn't get this to work.
Vehicle jump speed too fast.
1077 2 2-
- cheesetroyer
- Member
- 52 posts
- Joined: Nov. 2016
- Online
-
- David Krepelka
- Member
- 15 posts
- Joined: May 2020
- Offline
You have to add the calculated velocity to the object at that frame it gets activated (in this case at Frame 22, because >21). You were right to calculate the velocity with the trail, but when a rbd objects gets created with a initial @v value, it only uses that value on the creation frame as an initial value. But on the creation frame your object is set to animated, so the @v value is basically ignored. You could save the calculated velocity on the activation step as an additional attribute (for example v@init_vel) and for your attribute wrangle do:
That should do the trick!
if(@Frame==22){ //if you use ">" it would add the init_vel every frame i@active = 1; i@animated = 0; v@v += v@init_vel; }
That should do the trick!
Edited by David Krepelka - March 22, 2023 17:06:38
-
- npetit
- Staff
- 394 posts
- Joined: Feb. 2008
- Offline
We added an option on the RBD Bullet Solver SOP to add an "age" attribute to the RBD pieces, as well as an "active_age" attribute and Just Activated group to make it easier to inject entirely new forces into the sim on activation. This helps identify pieces that have just switched from animated or deforming to active.
Here's an example of how it can be used to do what you're after. Notice though that by default the RBD Bullet Solver updates the v and w attributes on the animated RBD pieces so when they switch from animated to active their momentum is preserved - no need for any v or w injection.
Here's an example of how it can be used to do what you're after. Notice though that by default the RBD Bullet Solver updates the v and w attributes on the animated RBD pieces so when they switch from animated to active their momentum is preserved - no need for any v or w injection.
-
- Quick Links