The Re-Inventing the Wheel Thread

[0lento]

Hi HunterPT,

since some of the points you’ve mentioned are based on my code snippets, I’ll try to explain the reasoning behind them. Do note that I haven’t fully read all the code of this plugin so can’t comment other parts of the correctness of it.

@HunterPT;507162

The next error I found was here:

if (!bOnGround[Index]) {PreviousPosition[Index] = SpringPosition;}

This is incorrect because if it was not on the ground it means that previous position was the TraceLength not the current position, in my case I just eliminated the entire if and passed the assignment of previous position to the else

			else {
				bOnGround[Index] = false;
				SpringLengthArray[Index] = TraceLength;
				/*Much Like SpringPosition, PreviousPosition is not the position but the length*/
				PreviousPosition[Index] = TraceLength;
			}

Although I would change the if to be !Hit.bBlockingHit to change the order of things so the code is clearer to read, but that’s a matter of taste. The results of this fix will barely be noticeable since it only happens during the tick where the wheel touches the ground, it is still incorrect.

That’s something I put into my initial substepping example here: The Re-Inventing the Wheel Thread - Community & Industry Discussion - Epic Developer Community Forums
To be honest. I’m not quite sure why I put it there. Basically only thing it does on it’s original form is that it prevents damper to counteract when you return to ground at that specific moment but that’s about it. I’m sure there was some logic behind it but I really can’t remember it anymore. Anyway, removing it should be just fine.

@HunterPT;507162

The next piece of incorrect code I found was this:

FVector TotalForce = Hit.ImpactNormal * FVector::DotProduct(Hit.ImpactNormal, SpringForce * BodyUpVector);

This creates a problem in extreme angles between the car the ground, where the total force that ends up being applied is far lower than it should have been, and for this to be correct it would also mean that the very way in which the traces are made would be incorrect, since the angle in which they are made should at least in a simple model like this represent the way in which the forces are applied.
The correction I believe is this

FVector TotalForce = BodyUpVector * SpringForce;

I suggested TegLeg to try that dotproduct there. You are right about it not being fully correct but just using UpVector * SpringForce isn’t either. What I suggested there is a compromize that works most of the time well and I didn’t find any bad side-effects for it.

I’m explain this bit further:

For example, if you just do BodyUpVector * SpringForce and have your vehicle aligned so that front of the body is lower/higher than it’s rear., then that force will actually push the vehicle slightly forward/backward as well, also sideways if body is leaning left or right. On inclined surfaces, this is correct, but if your wheels are on even surfaces (think about stairs or any steps for example where the tires itself are on flat even surface) your vehicle should stay still and not move at all.

If you calculate suspension force by multiplying it by linetrace’s hit.normal like I did on my original code snippet (which wasn’t meant to be used as vehicle suspension as is), then it would work on that stair example right, but it would mean spring actually acts in all directions instead of just up.

So the compromize I suggested was to use that but for only the part of the force that can act in vehicles up direction (assumption that springs move directly up and down in this case), it’s kind of combination for those both but in extreme angles it just gives you too low values. Again this isn’t fully correct way to do it, but if you want to do it right, you have to take a lot more forces into account for the wheels themselves.

@HunterPT;507162

Finally I believe the AntiRoll model is not correctly done, I haven’t done proper testing on it since it was the last part I checked so take it with a grain of salt, but I believe the assignment of AntiRollForceF should take zeroed FVector(0.0f , 0.0f , 0.0f) instead of FVector() since from the quick test I did it would seem FVector() does not assign a 0 value vector, but instead the current position of the object or something (once again didn’t test it properly).
The entire model also seems to be incorrect if the model that I believe inspired it http://forum.unity3d.com/threads/how-to-make-a-physically-real-stable-car-with-wheelcolliders.50643/ is to be believed, the original model doesn’t use forces and does things all around differently.

		float AntiRollForceF = ((SpringLengthArray[0] / TraceLength) - (SpringLengthArray[1] / TraceLength)) * AntiRollFront;
		float AntiRollForceB = ((SpringLengthArray[2] / TraceLength) - (SpringLengthArray[3] / TraceLength)) * AntiRollBack;

		if (bOnGround[0]) {
			SpringForceArray[0] += BodyUpVector * -AntiRollForceF;
			BodyInstance->AddForceAtPosition(SpringForceArray[0], SuspForceLocation[0], false);
		}
		if (bOnGround[1]) {
			SpringForceArray[1] += BodyUpVector * AntiRollForceF;
			BodyInstance->AddForceAtPosition(SpringForceArray[1], SuspForceLocation[1], false);
		}
		//back
		if (bOnGround[2]) {
			SpringForceArray[2] += BodyUpVector * -AntiRollForceB;
			BodyInstance->AddForceAtPosition(SpringForceArray[2], SuspForceLocation[2], false);
		}
		if (bOnGround[3]) {
			SpringForceArray[3] += BodyUpVector * AntiRollForceB;
			BodyInstance->AddForceAtPosition(SpringForceArray[3], SuspForceLocation[3], false);
		}

I’ve made that same point earlier on this thread too. There is force involved as AntirollCoeff though (its 5000 N/m on that Unity example). In vehicle dynamics literature, antiroll bar is sometimes approximated in form of ForceARB = AntiRollCoeff * (SuspensionPos1 - SuspensionPos2) which is essentially what you are doing there. You may normalize the values to tracelength like you do there, but you’d just need to use bigger Coeff force then. By the way, there are ways to calculate that force coeff from ARB dimensions as well but in the end, since this is still a very rough estimate, you’d just find a good value that keeps your vehicle from tipping over too easily.

@HunterPT;507162

I believe the code above would be the correct implementation of the other model in UE4, but once again haven’t really tested it properly so could be wrong, and if I am please do correct me on it.

If you want to share your version of the fixed code, it would probably help others the most As a side note, I think that if people want to build a community based vehicle model, it should probably be in github etc place where it would be easier to manage and get people’s pull requests and forks handled better.

That being said, you may also want to check BoredEngineers MMT-plugin ( [OPEN-SOURCE] Machinery Modelling Toolkit - World Creation - Epic Developer Community Forums ) as he’s done lots of vehicle related things there as well. MMT is still missing 4-wheeled vehicle example but I think if people concentrated on one community based open source solution, it would benefit all. Most of the actual content there is implemented in BPs but it shouldn’t be that hard to convert those into c++ or eventually build both c++ and BP examples for different types of vehicles.

If you have any further questions / thoughts about vehicle physics, feel free to ask here or come join us at UnrealSlackers or #unrealengine IRC-channel @freenode.