Thanks for the reply,
I saw your motive for that dotproduct a few pages ago, but I completely misunderstood what you meant at that time, now I understand and yeah I tested it and definitely a problem on stairs, had completely missed it so thanks for pointing that out.
It does however have one advantage in what concerns the tegleg 0.4v, in that if you put the car in some stairs with the dotproduct the car won’t go down the stairs on it’s own, while with the bodyupvector it will, now it’s obviously going down the stairs for all the wrong reasons, since that kind of force shouldn’t be coming from the suspension but it still leads to a more realistic looking behavior in this very specific case, although you can’t put the car backwards on stairs as in some positions (not always) it will try and climb the stairs on it’s own, which safe to say is not a realistic behavior.
Anyway at this moment not quite sure what the correct solution to the problem is, although there is one very hackish yet likely effective solution to the problem, which is to use your dotproduct solution then check the vector magnitude with .Size() compare it to springforce and if it deviates by an X amount it applies the bodyupvector solution instead, since if it deviates by a good amount it means the situations is one where the BodyUpVector is more correct.
BTW testing out the stairs situation I did run into another possible bug, but haven’t check to see where it comes from, the bug is that if one removes the suspension calculations, which effectively puts the car completely on the ground, when turning the car is able to make a full turn on one side, but on the other side it only turns so far, this might not be a bug with the code, it is possible that it’s the collision mesh that is non symmetrical and causes this issue, and ofc it’s something that won’t happen in a realistic use case scenario, but it might be indicative of some incorrect piece of code.
As for the anti roll bar yeah prefer to input the values manually for that, they aren’t all that hard to tweak, and for my specific case I will only have 1 vehicle so the extra work is minimal.
Unfortunately don’t have any more code to share, I mean I could share the entirety of my code, but everything that I didn’t already share is the same as the tegleg 0.4v so it’s not of much value, anyway going to start my own implementation of vehicle physics, just used tegleg to get a grasp on how to use substepping, UE4 physics and so on, since I had never programmed in c++ or used UE4 before, although I won’t be able to share that one, not that it would be of much use to most people anyway since it’s going to be for a somewhat unusual vehicle.
Boredengineer work looks quite good, had seen it before, he was actually featured on the unreal engine sequencer twitch stream yesterday.
Since you are offering to answer questions I do have one question, I saw this article http://www.aclockworkberry.com/unreal-engine-substepping/#Fixed_Frame_Rate and in it he mentions the following:
“Finally I’m defining some utility inline functions to get position, rotation, velocities directly from the rigid body. This because body transformations aren’t updated until the end of physics tick, so you have to read them from PhysX rigid bodies to get the updated values from the last substep.”
Basically unless I’m missing something he seems to be dealing directly with the Physx objects, and I’m not quite sure why he is doing that, he says that you need to do that to get the updated transform values from the last substep, but doesn’t using the FBodyInstance* BodyInstance give the same results, I have setup a counter and logged both the counter and the body location after having heavily decreased the Max Substep Delta Time, and unless I have done something wrong the FBodyInstance* BodyInstance was reporting an updated position of the BodyLocation in each substep.
Thank you.