Build: 4.7.5 Branch: Binary, from Launcher OS: Windows 8.1
Disclaimer: GIF image is a bit long. Important findings are shown in the middle to latter parts of the GIF.
Thread discussion here. It was confirmed by another user that this is a bug. I am not sure if it has been reported or not, but the AnswerHub search doesn’t give me any results related to this issue.
The problem occurs when I called on AddForce() once throughout the entire life in the level. After calling AddForce(), the Actor (here, it’s a pawn) will never completely stop. The Actor has a USphereComponent, so the angular damping affects the force as well as linear damping on the USphereComponent.
Even if I increased the Angular Damping value to 10.0f, 100.0f, or even 1000.0f, the numbers in the X, Y, and Z fields in the Transform category will continue to change. I would be seeing the numbers change by tenth, hundredth, and thousandth in the mantissa part of the fractions, respectively.
I am expecting the damping values to gradually decrease the speed on the actor to the point of making the Transform slowly stop completely. However, the damping value is not working. It is just damping the Actor’s current momentum by the Damping value, and resets the momentum the Actor has.
The solution is to call FBodyInstance::UpdateDampingProperties after setting your new Angular Damping value!
This apparently is not being done if you set the value using the Editor UI
Here’s the code for it, will make BP node shortly
UPrimitiveComponent* Comp = GetYourComp
if(!Comp)
{
return;
}
FBodyInstance* Body = Comp->GetBodyInstance();
if(!Body || !Body->IsValidBodyInstance())
{
return;
}
Body->AngularDamping = your new value
Body->UpdateDampingProperties(); //<~~~ this is what UE4 needs to do properly in PostEditChange of the UI code
I am not actually sure if the editor even CAN update this properly, since the Body instance doesn’t exist until runtime, something needs to be updated in the Body Setup that isnt (Epic, your turn)
#Edit (EPIC see this plz)
I just tested this issue in 4.7.5 and everything works correctly.
The infinite rolling is not a bug, but just a part of PhysX simulation.
Ori has added some code to affect this when needed. This will be game specific though depending on what is being done.
Using 4.7.5 when setting the angular damping I’m seeing the same results that Rama is with the ball coming to a rest with damping set to a high enough value.
I tested using the C++ code to call on UpdateDampingProperties(). As far as I can tell, it doesn’t seem to work. The ball moves on the XY plane after dropping from the air straight down without any forces applied, and the Y axis increases more than the X axis. The floor itself is a default static floor with no rotation, so I really don’t know what physics PhysX is simulating.
@ Tim Hobson
I can understand why a perfect sphere would roll infinitely assuming there is no damping or friction but that is not the case!
Currently, spheres ignore friction and they never completely stop (even with high damping) so it doesn’t matter if it’s “just a part of PhysX simulation” or not… it’s simply wrong!
I think this problem has been ignored long enough… we basically need to write our own custom physics code to make spheres behave even remotely realistic.
I’m pretty sure that this is not a project-specific thing either! we are just asking for normal, common sphere physics here.
The reason for the speeding up roll is based on the way physx generates contact points. There are two approaches and they both have advantages. The current default behaviour is designed to get stable stacking of boxes and objects, but comes with inaccurate contact points. The new option, which can be turned on in the project settings as of 4.8, generates accurate contact points but with reduced stability of stacked objects.
In the case of spheres rolling, inaccurate contact points cause the simulation to gain energy which causes artifacts.
The game specific part is that you need to decide which feature is more important for your project.
Does that mean setting the damping values to very high numbers in the editor will not have any effects on the simulations for rolling spheres? And therefore the editor not updating the damping values mentioned by Rama is not a bug?
