i’m not exactly sure, we can physically animate other bone colliders like below:
so your animations are not physical but driven by animation or just manually tranformed?
I think he meant animations driven via the animBP. those are not possible if there is a physics body associated with the bone to be animated. The dump truck sample has a physics constraint which we are changing its properties via tick in the vehicleBP not via the animBP.
@lazybitgames Having in mind the camber sign is actually wrong at Front/Rear axle(as we confirmed), is possible the params related to camber at Fx/Fy/Mx/My/Mz from tire models 96 or mf61 are giving a wrong/inversed value calculation?
I mean, actually using positive camber values to get the same visuals as if they are negative in real life.
Due that, wonder, if tire models are using that value as multiplier/reference, then Lateral, for example: PKY3(0,2), PDY3(-11,23) & PEY3(-0,083), that are based on camber, are giving wrong output ¿?.
Because i feel there is something that not works as it should on cornering that bugs me.
My first guess was that, second maybe another sign inversed code or tire_BP, because playing around in tire BP changing some signs seems the car feels better ¿?
Im still doing some debug to see if i can find what is it, but, can you double check please? so if is ok i can discard that thing.
I have checked the camber, in fact the camber value has correct sign in tire force calculations, the problem is only visual. roll rotation is clockwise in unreal and anti-clockwise in unity. so the only fix needed is in UFGearWheel::getWheelRotation, we need to negate the camber angle there.
1 Like
Ok thanks for check!
I found a bunch of complete values im testing and seems for the same value can be negative or positive and result can differ a lot even if value is pretty small.
Also CombinedLongitudinal, which are zeroed in tire96/MF61, tried all i found and all gives a worst feeling ¿?. Guess you tried too and let zeroed?
After more tests seems problems comes from load params, changed Nominal Load 5000 to 6000 and car feels more smooth/responsive.
Same for lateral coefs, if inverse the sign of PKY1 & PKY2 the car cornerring is similar but in someway less erratic and more smooth/predictable, i dont know, still testing.
Hi @lazybitgames finally found out what was causing the issue , when you put a large box collider inside the FGEAR pawn , the center of mass is based on the pawn’s bound box , if you put the box inside a scene it will be ignored
Finally found the issue, is at COMBINED LONGITUDINAL, due zeroed.
Seems to be at RCX1(Cxa), all values tested were in the 1-1.5 range, but setting 0.1-0.15 fixes the problem.
After fix, trying again some set of params for that category, driving improves, cornering under brake/accel, the bug i was talking in previous post is almost fixed, guess now just needs some value tweaking.
Now driving is more smooth and accurate, without annoying fast impulses or erratic behaviour under some scenarios, guess due the lack of that values for correction.
Can you double check “combined Gx” in tire models .cpp ?
Implementation seems correct, so maybe there is some units / scaling mismatch? (degrees/radians or similar)
EDIT: Cant get the final feeling fixed in all scenarios, so or is hard to tweak and needs more time to invest, the RCX1 value needs to be lower or maybe the correction is at some RBX1-3 combination. Whatever it is seems is a reduction of the final output to be less extreme and avoid break the driving.
I didn’t see any issues in “combined Gx” section.
the only potential problem might be with the “Vx” input. it’s unit is cm/s but the reference parameter called “VREF” looks like m/s and it’s default value is 16.67 which is about 60kmh.
setting the VREF parameter to 1667 (100x) would fix the unit issue. this input is only used for rolling resistance calculation though.
Then there is something, because i checked lots of parameters sets from pdfs i found, .tir files, or even your default values for Combined Longitudinal, and all they breaks the driving because the output value is too extreme.
The fix that better fixes the problem after lots of tests in all them, in all scenarios, is multiply the RCX1 value proposed by 0.1, so set there 0.1 instead of 1.0, makes more subtle and worth, you can test.
After that, the driving behaviour improves and is better than being zeroed, as said, mostly noticed on cornering and/or brake/accel.
No idea if you already checked but give a look it too at this possible scaling issues: 1. Some units / scaling mismatch elsewhere (slip, ai, camber, Bxa, or Shxa) or - Pastebin.com
EDIT: About the VREF i double checked and removed lot of testing stuff, and 16.67 seems fine, increasing vref 100 makes at certain speed no rolling resistance increase or so small, i dont know if thats accurate. But checking the .cpp it multiplies by QSY3 and other stuff, so maybe with a fixed units it makes sense. Im using mCombinedTorque.Y to be used in mWheelTorque for rolling resistance and works for me.
I’ve been testing and checking ranges for each param, some are positives, other negatives and possible variations, mixed them,etc… but the effect over the car is always extreme, reducing too much the mLongitudinalForce. This is some of my tests.
Maybe implementation, units,etc.. are correct and behaviour is what expected for a real car, but from 8 categories where i tested different values sets i found, Combined_Longitudinal is the unique that filling using the values proposed breaks the driving, making the car stop or stuck sudden.
Due multiply RCX1 by 0.1, still not 100% happy with the final result, maybe i need to decrease everything a % to get it right and not only one, will continue testing.
@lazybitgames I think found what is happening.
Combined Longitudinal output(Gx) should be between 0-1.
His objective is reduce the Longitudinal force based on slip, being the usual range ingame around 0.3-1.0.
The problem is that the actual output can give values bigger than 1(more friction force than available) and even negative values, giving that sudden stops i was talking about.
So i will say its definetly a scaling issue, because it adds or decrease more than it should.
Thats why reducing RCX1 helps with the problem, but not gives 100% expected results because seems all them should be reduced to be accurate.
/
Then, if you double checked, and the formula, scales and implementation are fine as they should, then we need a missing category:
The category missing is called “[SCALING_COEFFICIENTS]”, “[SCALING_MOMENTS]” or “[SCALING_FACTORS]”.
In theory should be on both: Tire96 & MF61, Sources:
https://optimumg.com/wp-content/uploads/2019/08/OptimumTire_Documentation.pdf (Pag. 146-147)
PAC2002 Magic-Formula Tire Model | PDF | Tire | Speed (Pag. 19)
Also in that category should be scaling for “Pneumatic trail” & “residual torque”, that looking MF61.cpp is called “residualMoment” ?
What you think?
Just wanted to come back and say that FGear is THE most versatile vehicle system I have had the pleasure to work with. So far, I’ve implemented 4 wheelers, tanks, bikes, horses, cannons and aircraft. Next up is boats
PS: For the aircraft, the actual flying part is a separate implementation, but the ground movement is still done by FGear, also, the fact that a single FGear base class works for all of these different vehicles is pretty ■■■■ impressive in my opinion.
4 Likes
the scalers may solve/hide your issue but at the end of the day that’s just tuning.
I did a quick check on the pacejka’s book and I saw a couple of spots where I missed some constraints, the formulas are correct but some values need clamping. I will go over the formulas and fix any missing constraints.
1 Like
That’s awesome. That’s one of the reason I’m sticking with Fgear. Just trying to fine tune handling and drifting. @lazybitgames hopefully a new update is on the way.
1 Like
a minor update will come with 5.7 release.
the work on the big update is still in progress.
3 Likes
I see ok!, yeah just tunning, but i can use real params/ratios on combined longitudinal, and use scalars to fix the peak longitudinal or where it fails, instead of redo all combined longitudinal params to get my own version working in FGEAR for my needs.
But no problem, while you add the constraints guess for now will add a 0.2-1.0 clamp and scalar in the MF61 tire for Gx that should work in a similar way, will test later if goes better than just reduce RCX1.
@lazybitgames Found a possible bug in Combined Longitudinal:
In theory, increasing RBX2, which depends of slipratio(k), should give lower values if slipratio rises on final Gx, but it does the opposite, meaning that when more slipratio = less longitudinal force reduction = more longitudinal force at higher slipratio.
I did the debug with default MF61 values, btw i tested others and it does always the same.
EDIT:
Seems changing the cosine by sine fixes, maybe that was the error? no idea if thats accurate? or there is another way to fix. All inte case as i think, lng force should decrease when slipratio increase.
float Bxa = (RBX1 + RBX3 * yi * yi) * FMath::Cos(FMath::Atan(RBX2 * k));
By
float Bxa = (RBX1 + RBX3 * yi * yi) * FMath::Sin(FMath::Atan(RBX2 * k));
here is the formula from the book:
the only missing part is making sure Bxa is positive.
Seems the problem is not the Bxa formula itself, but how G0 is handled. Using SIN gets the expected behaviour for that param but not the correct way to fix, can you take a look to this?
“Your implementation is not the canonical normalization used in the Pacejka combined formula.
Because you compute G0 with the same Bxa that depends on k, the denominator shrinks when k (or RBX2) increases, so the ratio can increase — which is the behavior you observed.”
In the canonical / intended normalization the denominator is evaluated at a fixed reference value… “
More info about the possible issue:
I have no idea if this is correct. too much maths for me, but i will say the formula to be accurate for realism, lng force should increase at small K and decrease when K increase at high levels, and now seems it does the opposite.
EDIT: Or maybe your implementatios is fine and instead of increase RBX2 i have to decrease it and fine. Btw, for RBX2 all i find is 0 or negatives, but your default value is positive.
@lazybitgames Can you double check the REX1 sign?
Ive been testing all day and checking values from papers and in all them are REX1=Positive and REX2=Negative. It gives Exa=Positive, which result in a more rounded and smooth curve, making the cornering feel good.
Actually, MF61 tire default values, REX1-2 are both negative, resulting in Exa=negative, giving a more sharp curve and in theory non-physical based and not recomended.