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.