In principal wheels can be rigid bodies without soft physics, but to make them stable and avoid jittering you need to process collision in a custom way. I’ve seen tank implementation where collision of drive wheels with the ground was handled as a spring contact not as regular rigid impact. Spring force itself is later used in friction calculation. The amount of spring force is proportional to penetration depth during collision. Pushing wheels above the surface is handled not using impulses but the spring force itself.
I have zero idea how you could implement this with Physix in UE4 as collision processing is handled on a low level and in UE4 you get only collision response, but what you need is to override the collision calculation itself. In demo with tank which I’ve seen all physics where custom made.
That’s the point I’ve been trying to make here as well. You just can’t have rigidbody on rigidbody collisions integrated with physx and expect it to work like it does on those simulators (which use highly customized physics engines).
Yeah, I’ve been trying to get to the bottom of this, but I can’t for the life of me link the debug physx code with ue4. This makes stepping through it nigh impossible. I need to do this in order to see where everything comes into play in physX code. As it stands now I can’t tell if the changes I make have any lasting effect, which is infuriating. Part of the problem is due to the fact that the whole setup for dll placement has to do with the VS version. This complicates issues because I’m compiling UE4 in VS2015, as well as compiling the PhysX in VS2015, but UE4 only has it listed as being compiled in VS2013, but has precompiled dlls for PhysX from VS2015. I’ve tried changing the location and outputs of file types, to try and replace them, but everything I do breaks UE4, all the way to the point that I had to redownload and recompile the whole engine. But I haven’t my engine successfully compile since. These problems are very disheartening.
I took a break the last 2 weeks and have been working on AI in Python, and just writing some fun programs in there. I’ll get back on this some time today though.
The master version has the files for 2015, so that’s what I’ll be working out of from now on. Maybe I’ll have some luck.
wishing you a big bucket of luck
totally know what your going though, ive had 2 or 3 tries at fixing it over the last year or so.
Hahaha, I back-ported the PhysX code from 4.12 into 4.10.1. So now it compiles with VS 2015 with no problems and now I’ve got the debugger to work as well so I can step through the PhysX code finally. But now I’m tired, so I’ll mess with this tomorrow. It should be significantly easier to modify the PhysX code when I can see the repercussions in real time, or some facsimile of it.
Reporting to everyone here, I have successfully implemented Ackermann Correction for my custom NWheeled Vehicles, witch is pretty much the same as did. Obviously, it is a PhysX source code modification and some new lines of code inside our NWheeled class. Also, made some modifications on standard UWheeledVehicle class (4W) , so you can add more than 4 wheels without breaking it. My next attempt will be porting the 4W Differential options to the NW class. Wish me luck! :o
Looks like things have slowed down a bit, but it also looks like a lot of progress has been made. Hopefully Epic can begin incorporating some of this work at some point.
All I can do is offer moral support.
Well basically I’ve come up to a dead end at the moment, all attempts to fix the wheel on wheel contact have failed. This is due to the fact that attempting to do anything with the eKinematic response for the rigid bodies crashes the system due to a weird Memory error. Somehow it knows that the rigid body is kinematic but attempting to react to that deletes the rigid body from memory and crashes the system. PhysX is quite a complicated system so diagnosing why this is the case feels a little beyond me at the moment. I’ll keep working on it here and there but this kind of error really killed my motivation for doing so. I prefer to spend my time working on things that are fun, of which this is not. So hopefully PhysX 3.4 comes out some time soon and it gets fixed as a by-product. As it stands now, I’m making a vehicle using constraints, but that comes with it’s own list of issues.
bah
same result as me, was kinda hoping you were on the case there, oh well.
Well, tried at least…
Since we don’t have a solution for this right now, I would like to share that I could add a new feature to the list : Camber angles.
PhysX already have it implemented, but was missing on UE integration. Now, it is possible to adjust camber at rest, at max droop and at max suspension compression.
It works like an independent suspension, but I’m trying to make a way to simulate camber angles on rigid axles.
absolutely
forgot to say thanks for trying 
yeah theres a bunch of stuff like camber angle that is in physx but not exposed to ue4, shame it wont fix the main issues though.
I really would love to understand what are those main issues with PhysX on UE4, since at the moment, I did not created anything yet, just preparing the engine for my hobby project, which is related to trucks and trailers. So, with this information in hands, I may be better prepared to face those issues…
here you go, its a lot to get through
https://forums.unrealengine.com/showthread.php?48843-Horrible-Car-Physics
basically,
there is something wrong with the way suspension springs are calculated, meaning its all too easy to send a 30+ tonne vehicle flying into space from mounting a curb for example.
wheel on wheel collision is also guaranteed to send vehicles pinging round the map, there are countless other minor issues that probably stem from the same root cause.
as for trailers, the physx vehicle uses a single bone/single rigid body so a trailer would have to be something of your own construct that is attached somehow to the vehicle.
take a look at boredengineer’s tanks for a good alternative to the standard vehicle, it also includes one with a trailer.
best of luck, you will need it if its a vehicle based game.
Uhn…Ok, I’ll have a look at this and try to reproduce those errors to get something to work on.
I already saw on PhysX Dev Forums some other guy making the same as me, a truck and trailer simulation. Attachment was done by constraint and the trailer built under PxVehicleNoDrive class… it has a bug on it, but, luckily, there is a workaround explained there too.
Oh, and thank you Tegleg, not just for the answer but, I wish to be thankful for your tutorials on YT, specially the Spline Road, was very good to me.
I found out the curb issue for launching the vehicle into the air, if you have handle complex collision as simple checked, and you didn’t add actual collision to your object, that’s what causes that. I’ts easily fixed by adding custom collision to it. As far as the wheel on wheel interaction, that’s caused by the vehicle class not having any code to handle the situation, and my attempt to add code to handle it exposed a deeper problem with the PhysX code in the way the vehicle is being handled. The person that wrote the physX vehicle class and the person who implemented it into Unreal are the real people that need to collaborate to fix this. It could be done fairly quickly if they were to have a go at it. It’s not a math problem, as the conversions are correct. I’ve modified a lot of the calculations to find the cause, and the way the calculations are done is correct until the vehicle gets launched into the air. I also added the tire force application point so that it and the suspension force point could both be modified, to see if I could more finely adjust the forces, but it has no bearing on the real problems, so I didn’t feel the need to mention it.
I’m not so good as you guys understanding this whole thing, but, this could help?
If I understood, we can’t use Complex collision as simple with vehicles, is that right?
For the environment assets is what I meant. For instance in the advanced car template, I would sometimes get the vehicle launched into the air when I hit a curb, this was fixed by viewing the static mesh asset and auto-generating collision for it. As it stands now all those assets are marked to use complex as simple. I’m not saying you can’t use that but it doesn’t seem like it’s a good idea in general, not to mention it causes issues PhysX on occasion, it’s better to make your own. Though generating it in ue4 is pretty simple, it can leave you with varying results, but works just fine in a pinch.
Good news on EPIC’s front, the PhysX 3.4 integration is scheduled for March.