As a side note, not sure if there’s “proper” way to calculate all these approximations, I’d just go with what feels close enough for arcade game If you calculate those forces completely decoupled and never correct them after combining, you could get odd behavior on certain scenarios where your tire would have still maximum long and lat grip simultaneously, which isn’t possible in real world.
There’s a concept of friction circle which means that there’s only certain amount of friction that tire can handle in any situation. This page explains it in simple way: Friction Circle (The Basic Theory). In reality, that friction circle (or traction circle etc) is more shaped like oval than perfect circle.
First, divide RPM by 60 to get rotations per second. One full rotation is 2Pi or 360 degrees so multiple it by one or another (I don’t remember what AddRotation() function needs as input). Multiple result by DeltaTime and call AddLocalRotation() - it will nicely handle cases of sign and going over 2Pi/260 degrees.
DeltaPitch = RPM/60.0 * [2Pi;360] * DeltaTime
AddLocalRotation(0.0, 0.0, DeltaPitch) - not sure if the pitch is last or second argument.
Exactly. I think I did math only on paper but looking at code I didn’t implemented it. The simplest solution is to clamp vector summ of X and Y friction by a max(MaxXFriction, MaxYFriction). The math I actually needed was to derive the portion of X friction which is left after clamping. Which as I see now is just X component of the total friction force. Don’t know why I didn’t implemented it
I believe unreal uses SI units for physics with an exception that default unit for length is centimeter (Unreal) instead of meter (SI).
For example, if you calculate force using newtons second law of motion, you’d normally use this:
N = kg*m/s^2, where N is unit of force.
As unreal uses cm, your force value would need to be 100 times bigger to get the same result.
I thought about this little more and what I wrote is not right. I’ve seen it done like I described on many raycast cars implementations but it would actually add wrong forces when springs are compressed individually. For example if front of the vehicle is compressed, it would move the vehicle forwards a bit as well. In reality, spring force just pushes the wheel down and the part of that force that gets to ground should be based on tire contact instead. You could probably get both the spring force direction and ground normal taken into account using something like this:
It should filter out forces that don’t go along with current ground normal but still only apply forces that spring can produce on it’s direction. Not sure if that’s still fully correct but at least it should behave more realistically with that.
using that formula, when landing at a strange angle, the car is sent spinning off into space.
somewhat similar to the standard vehicle. does anyone happen to know how the physx car calculates the spring force?
I saw on that 0.3 version which you posted earlier that on certain angles the body gives self positives for the line trace. For example if you just rotate the vehicle so it’s front up in 45 degrees and hit play or simulate, it sometimes goes crazy because linetrace gives hit at zero all the time. It’s possible it’s same what you are experiencing now. You could try swapping the line trace from channel to object type and then use just physics only setting on the body collider (by default it enables collisions for querys and physics).
So instead of that channel thing, you’d have something like:
since v0.3 i added this so the trace ignores the car
TraceParams.AddIgnoredActor(this);
ive been meaning to change the trace to objecttype as well as using shapes.
vehiclewheel seems to use a static mesh for the trace sweep but it looks like a whole heap of messing, its on the ‘to look at properly later’ list.
edit:
actually its probably not far off the next update, added an engine and gearbox and revised the grip calculations.
just need to do some final tests/tweaks and tidy the code up.
it is 4x4
not sure how far i will take this, tbh a simple arcade car that doesnt ping off into space is enough for me.
im also working on another version for articulated vehicles
i think i may have just found the main cause of problems in the standard vehicle.
ive been messing with anti-roll forces and can reproduce the space launch bug with my vehicle code.
it happens when, in 1 sub-step, one side spring goes from full length to 0 length, and at the same time the other side spring is full length but on the ground.
this means something like double the max suspension force is suddenly applied to one corner due to anti-roll being added to that spring (at full strength already), coupled with the rigid body ‘rebound’ from hitting the floor and exaggerated by any lateral grip forces depending on the angle of impact, means instant flight.
could be wrong, just a theory thats come from my experiments.
there may be some delay with the next update…
I did take a look at your 0.3 code and I saw now that you are doing anti-roll using spring forces. This isn’t the right way. You should compare the difference between each sides spring compression instead and multiply the difference with the spring stiffness and use that as you antiroll force. You could use some stiffness value that feels right, but if you want to calculate it, there’s a formula for estimating it on this page.
As a side note, I haven’t seen any space launches on my own prototypes as long as my collisions and forces have been properly setup.
If you calculate those forces completely decoupled and never correct them after combining, you could get odd behavior on certain scenarios where your tire would have still maximum long and lat grip simultaneously, which isn’t possible in real world.
