This can happen if you are getting a framerate of lower than 30fps. The reason is that we cap the delta time passed into PhysX for stability reasons.
If you turn on sub-stepping it should remove the capping which should give you the exact floating you’d expect.
Welding is still in early days, but we’re really interested in making it work so I appreciate your time and effort!
The reason why bWeldSimulatedBodies = false by default is due to preserving existing content. This feature was added fairly recently and we didn’t want to change existing behavior of projects.
If you wouldn’t mind PMing me with the case where welding is broken I would really like to see it so we can fix all the edge cases.
Using a PhysicsConstraint will work, but it has several drawbacks:
- It’s a constraint which means it will not have perfect behavior (it may separate for a few frames depending on how the PhysX solver behaves)
- It’s less permanent than a single rigid body
Hi , thanks for the reponses! I appreciate all the effort you guys have put in, however don’t envy having to deal with all the issues. 
The problem in that case turned out to be a collision between the attached object and the parent. I’m guess I managed to accidentally set them so they were very close together, and there must have been some sort of precision error in the PhysX stuff such that when I turned one way they intersected and repelled each other causing the force, but if I rotated the other way they didn’t. Some kind of warning perhaps about self-collisions or a check during welding might help prevent a lot of unexpected behaviour.
Stripping out my code for the welding may be difficult, but i’ll see if I can set up a simple test case for you. I tried every permutation I could think of over the last few days, simulated, unsimulated, weld, no weld, and couldn’t get it to work. I just figured that welding was well tested. Might be worth putting a comment in the code letting people know it’s a bit experimental. Prior to welding, what was the preferred way to attach two simulated bodies together so they behaved as a single rigidbody?
Prior to welding there wasn’t really support for getting two simulated bodies to act as one. The closest thing was using a constraint, but this has drawbacks as I mentioned above.
Just found another issue that I can’t explain. I have a multiplayer game, but for some reason about 50% of the time when the players spawn, the listenServer version of the player pawn is frozen and won’t move. I’ve managed to track it down to GetPhysicsLinearVelocity() return NaN, and digging down I get Nan from PRigidBody->getLinearVelocity().
I don’t suppose anyone has come across this one?
Turns out it only happens in PIE.
Sounds like you may not have physics turned on for dedicated. Is the dedicated server checkbox checked in PIE?
Mesh->bEnablePhysicsOnDedicatedServer = true;
It’s a ListenServer. I hadn’t come across that option before though - thanks for pointing it out. Odd that it happens so inconsistently.
Rather than pollute this thread with my own issues, I’ve decided to create another thread to document my experiences.
@zoombapup - Do you honestly feel like regular game coders should be debugging and fixing something as complex (and it IS complex) as PhysX when it is supposed to be a very mature API produced and maintained by a whole team of experts?
I’ve worked in the games industry for nearly 20 years and at some prestigious companies. The vast majority of coders I’ve worked with, while more than competent in their own field, would have gladly left the physics to the experts due to its high level of complexity. You’re right in that understanding physics concepts isn’t too hard. But you’re dead wrong in implying that modifying the PhysX source code is within the remit of most C++ coders - just count the number of files in the PhysX source folder to see how ridiculous that statement really is.
Besides, should we expect these same kinds of problems with Direct3D or OpenGL? Perhaps fixing the Windows kernel too should be on our todo list? I’m not trying to be sarcastic, but instead trying to illustrate the disjointed nature of your standpoint. I believe the only real value of the source code for PhysX in particular should be for extending or enhancing the API, and not fixing such fundamental issues. Right now for example I just can’t get CCD to work effectively (yes, I’ve read the docs and source numerous times). Objects just shouldn’t be falling through the terrain when this feature is switched on, but this sure as hell is what is happening. CCD is not an advanced feature, and should have been a part of any professional API for the last ten years or more. Yet here, I’m spending quite literally days debugging this when it should just work and let me do my job of developing a game. After all, the reason we all bought into UE was to buy the heavy tech to do this stuff for us.
I wish this was the worst of it, but the list of problems I’ve had just goes on and on … it really should be better than this.
That is probably because the physics asset does not have the Use CCD checkbox checked. I ran into that one before. The C++ was setting it but the Physics asset itself wasn’t and would override it.
Not at all , it was certainly set - trust me I checked all of that stuff a dozen times. After extensive debugging, it turned out to be a secondary collision volume that was attached to the actor for detecting ranged overlaps was inadvertently turning CCD off. There was no CCD on this secondary volume, as it was query only and had no physics, but UE turned CCD off for all rigid bodies for the actor as a result, whereas it should just have turned it off for that particular rigid body only.
To underscore my point about the physics being pretty broken, now that CCD is working, I’m having very floaty collision responses with the vehicle I’m working with compared to quite solid, grounded responses I had before. But worse than that, I’m also getting very harsh (halting) collision responses when colliding with splines whereas before they were as smooth as you would expect. All I did was turn on a flag that said “make the collision more robust”. For my sins, I’ve now got all this fall-out to address in order to make a vehicle simply drivable, nothing more than that. It really shouldn’t be this hard.