Let’s say I have a box with a “wing”, a simple plane on the side:
█__
Both of them are physics driven, no gravity, and the box is controlled by the player (applying forces directly). I’d like to flap that wing like this:
█/
Simply rotating it so the overall shape of this whole things changes. It seemed obvious what to do: constrain the two physics simulated meshes. I disabled collision between them, limited rotation to a single axis, set up angular position drive.
Sadly the end result is kind of weird: When the box is moving around then the wing is lagging behind slightly as if it was attached with a rubber band and not a metal hinge. The angular position drive is also loose even with 999999 angular position strength, 0.01 mass scale and 0 linear/angular damping on the wing.
What I’d like to have is a very rigid, consistent, mechanical behavior: an infinitely strong hinge which makes the whole thing act as a single physics object. One which does not allow outside forces to move the two objects relative to each other, they only do that when I say so. No lag, no springy wobbling, no jelly like shaking. Is this possible?
Maybe the behavior I’m seeing is inherent to PhysX. Is there any other way to achieve what is essentially an on the fly collision hull change. The brute force approach would be making a series of single object colliders for like 16 distinct poses of the wing flap and swapping them as necessary but I hope there is a better way.
As it turns out it’s okay to set relative rotation directly on a physics driven component, the wing in this case. I still needed a linear locked constraint to keep it from flying off and to fix collision issues. Now the wing flaps as expected, something I did not manage to do with angular position and velocity driven constraint which was mess.
However the rubber band effect is still there, when the box moves the wing lags behind. Setting relative transform on it at every tick makes it snap back every now and then but it’s still a problem. Projection linear tolerance is at 0.001 but it doesn’t make any difference.
Something weird is going on: once in every 5 starts things work properly, welded together, no lag. Here is a short video showing the effect:
The first half is what I get most of the time, the second half is the proper behavior.
Projection tolerances are 0 and I set relative position and rotation for the green part every tick. As far as the BP game logic is concerned the green part never actually moves, when I print it’s relative location it’s constant even when it’s clearly detached from the red part.
It seems like a timing issue: the BP modifies position but then comes the physics calculation and overwrites that. Sometimes perhaps the physics ticks before BP or something and that’s when I see firm attachment.
I tested with max physics delta time of 0.3 and it alleviates the rubber band issue but unsurprisingly introduces massive interpenetration problems.
Is there such a thing as Unity’s LateUpdate so I can do stuff after the physics have been evaluated?
Changing tick group seems to have solved the lag issue at the cost of slightly increase interpenetration.
I followed Shadowriver’s instructions in this thread:
I made an Actor derived class in C++, set it’s tick group to TG_PostUpdateWork and reparented the related blueprint.
