The title may mislead you, so I will explain clearly here.
The ball is not stopping even after I stopped calling on AddForce() to the USphereComponent. I stopped calling on AddForce() when the ball is close to 100 Unreal units away from its target location, which the ball is at in the GIF below. There is no velocity and no acceleration added to the USphereComponent after that. I even have linear and angular damping set to 5.0f, yet it moves ever so slightly. 10.0f won’t even work.
The ball moves at a slow, steady pace. How do you completely stop the ball after applying force?
If you see the later parts of the GIF, it will show that I have already set the angular damping and linear damping to both 10.0f. Yet, the ball keeps on moving.
Either that, or I am missing something from your post. I am not sure if there are multiple components corresponding to different angular/linear damping that affects the physics of the entire actor object?
EDIT:
I just checked to see if 100.0f angular damping works. When the ball hits the ground, the transform location keeps changing values, but it is changing in the hundredth place. I set to 1000.0f, and I get the thousandth place.
I am so confused as to why it wouldn’t stop completely?
It’s a bug (which existed in UDK too btw)… basically a sphere collision shape is never put into sleep.
Internally there should be a sleep threshold that puts physics bodies to sleep when their speed is like 0.00-something but for some reason it doesn’t happen with spheres.
I’m surprised that this bug still exists pretty sure it has been reported in the past.
For now I suppose you can add a manual check when the angular velocity is smaller than 0.001 → put physics to sleep… but you should post a bug report in answerhub too.
But I do it via the body instance directly, and in C++.
Make sure to call this!
/** Update instance's linear and angular damping */
void UpdateDampingProperties();
**Solution ~ My C++ Code For You**
Here's some code for you to get this work, you could turn this into a BP node
```
UPrimitiveComponent* Comp = GetYourComp
if(!Comp)
{
return;
}
FBodyInstance* Body = Comp->GetBodyInstance();
if(!Body || !Body->IsValidBodyInstance())
{
return;
}
Body->AngularDamping = your new value
**Body->UpdateDampingProperties();** //<~~~
```
I will make this a BP node shortly and you can see if it works for you ( EDIT, compiling the BP node right now)
This is what I do in C++ and it works great
**I even update the Angular Damping dynamically based on how much linear velocity the ball has!**
Update: Everything Works in 4.7.5
I just tested your issue in 4.7.5
Drag an EditorSphere into the level (content browser->show engine content)
set simulate physics in the editor
set the damping to 300 in the editor
position sphere above angled surface
angular damping works great!
**More Info Is Necessary**
A. Can you confirm that if you do the steps above it works for you too?
**B. And can you then confirm whether AddForce() still causes the problem even if the steps above all work for you?**
C. And then you can say what happens if you use AddImpulse() instead?
♥
Rama
PS: Epic is not paying me to write all this, I am just doing it cause I care :)
Hi Rama, didn’t realize you are still awake at 3AM in the morning.
I am using 4.7.5 on Windows 8.1. The 4.7.6 Hotfix is for Mac only, so I didn’t update.
Some notes:
Do I call on UpdateDampingProperties() in the Tick(DeltaSeconds) update function, or just in the BeginPlay()?
For the angular and linear damping values over 300.0f, have you checked to see that the float values in the Transform category for X, Y, and Z all stop completely in the ten thousandth, hundred thousandth, and millionth place in the fraction mantissa? I checked mine, and the numbers are still changing at precisions near 0.0001 or below, so it’s technically not stopping. Don’t worry, I am still working on branching by toggling SetSimulatePhysics() flag on and off.
I made a GIF again showing that setting angular damping on my ball to over 100,000.0f still keeps moving. (This is the editor method, not C++ code.)
[list=4]
Your hint led me to a clue that AddForce() has nothing to do with the ball not completely stopping, but rather because of PhysX simulations after calling SetSimulatePhysics(true). AddForce() is basically a trigger such that the ball will have some sort of momentum that is really hard to remove completely after adding a tiny bit of force to the body instance.
Calling on AddImpulse(FVector) made the ball move more frenzy then AddForce(). I don’t even know if I should call AddImpulse() with the same amount of force I applied to AddForce()…
Edit: Since it is 3:30AM right now, I feel like fainting. I’m going to bed and will reply back on my C++ findings tomorrow. For now, the editor method not working gives an impression that C++ code may not work… Just an impression.
The infinite ball rolling bug is a bug in PhysX since the earliest versions of UE4. They were aware of it since at least a year ago, and it baffles me how this is still not fixed. In our game it’s crucial that the ball stops, and creating hacks around such things often creates unintended side-effects. Sphere physics. Infinite ball rolling - World Creation - Unreal Engine Forums
I did my findings for using UpdateDampingProperties() on the BodyInstances of each component, the USphereComponent, and the UStaticMeshComponent. It turns out the damping only reduces excess forces exerted on the bodies, but the simulation of physics continue to calculate minor forces, such as friction and gravity, on the bodies. I have completely commented out all AddForce() and AddImpulse() functions, yet the ball keeps moving, even when just dropping straight onto the ground that is perfectly flat with no rotated angles.
The numbers keep jumping upwards on the Y axis for some reasons I don’t know why. The Y axis distance increases substantially more than the X axis distance from the origin. The Z axis stays very close to 78.0f, which is the radius of the USphereComponent, measured from the floor up.
This still doesn’t fix the problem where friction has little affect on the sphere. The problem here is that for a perfect sphere the contact patch is infinitely small. However, if you turn PCM on and use angular damping you should get reasonable results.
Lovely to hear from your ! Thank you for UE4 Physics!
**A Ball That Stops Itself Is Possible Right Now**
I have not had any issues with infinite roll and I have a project that is based around a rolling ball, I am able to set the Angular Damping just fine like this:
```
UPrimitiveComponent* Comp = GetYourComp
if(!Comp)
{
return;
}
FBodyInstance* Body = Comp->GetBodyInstance();
if(!Body || !Body->IsValidBodyInstance())
{
return;
}
Body->AngularDamping = your new value
Body->UpdateDampingProperties(); //<~~~
```
The result in my game is a controllable ball that moves with WASD and stops very quickly after I stop applying impulses.
I write this just to let you know that it is possible! I am using 4.7.5.
Skeletal Mesh Ball Using Physics Asset
The only distinction I can think of with my ball is that it is a skeletal mesh component, not a static mesh component.
Asperatology, can you try using a skeletal mesh with a physics asset?
That’s what I am doing and it works great
Good luck!
Rama
PS: In the test I did in my post above I used a static mesh rolling ball and setting the angular damping worked just great there too, so I am not sure why I am able to get it to work so easily and others are having issues with it.
I did experience the infinite roll issue on my skeletal mesh ball until I added the Angular Damping as shown in code above, but that immediately fixed the infinite roll for me!
Skeletal? I have no idea how to do that. I may have to ask my team’s artists to help me with that.
Can you tell me where did you put your UpdateDampingProperties() function in? I am guessing it has to do with function call locations, based on your description.
Also, since I haven’t received confirmation from the Epic staff whether the editor not updating the damping values is a bug or not, what is your opinion? Do you suppose that issue is a bug?
I think that is a known issue. NVidia is aware of it since the inception of PhysX, according to a link given in the AnswerHub report link.
Hey Rama I have a question for you, is there a reason why you update the damping in C++? I have not tried that yet but the problem doesn’t seem to be the damping
The damping is actually applied without any C++ just fine (I can clearly see the ball slowing down faster) but unless you put some crazy-high value, it never completely stops rolling, it keeps moving really slowly forever.
But the thing is that there is no point in having a sphere with that high damping! you might as well put a box collision on the sphere at that point lol
Also, skeletal or not it doesn’t make any difference, the spheres are the same.
That sounds promising but if it’s a project setting that means you are forced to choose one or the other… is it possible to at least be able to enable this per object? or this has to be a global setting?
Also about the friction… are there any future plans to implement it? or this has to be done by the Nvidia guys? (sigh)
A side project of mine heavily relies on sphere friction so I’m basically forced to reinvent the wheel if I’m ever going to get realistic results
I will try the PCM setting when I get the chance though… thanks for that!
Yeah, today my artists said skeletal and static meshes are basically the same, the only difference is that skeletal meshes allow skeletal bones and rigging to a mesh, while a static mesh only conforms to the shape it is and is locked as it is.
After reading TK_Master’s post, I feel skeletal and static meshes won’t have an impact whatsoever with the damping properties and infinite movement.
pretty sure it has been reported in the past.
lol