Wonder how much can cost/time add proper tire collisions to the actual FGear Plugin?
Or for that may require a complete rewrite of the wheels part?. (Thinking to hire somebody)
Yes it is fairly advanced topics and one has to be comfortable with C++ first. It is not just following a few tutorials - but possible, if you sonehow can pick it up from there.
C++ however, allow you to do far more, and can be much more expressive in smaller code.
Itâs true, the physics are incredible, modifiable and all that, but Unreal with its collision physics completely ruins the experience, even with the physical materials the solution isnât complete
Yep, for me FGear is the best physics solution in UE rn at marketplace.
The unique better is one called XVP but for enterprises, includes proper tire collisions + deformation.
Here is a 23min video of DEV talking about his hybrid solution:
Maybe this can give some ideas to @lazybitgames to improve FGear.
In the comments, the conversation with âNewLife973â is interesting to know how is managed:
Hybrid solution with rigidbody, no colliders attached, collision handled by shape casts.
This is done in the way that colliders are not needed. All weights are considered.
The rigidbody of a wheel has an inertia tensor of a cylinder and spins to produce the gyroscopic effect.
You can set inertia tensor & rotation from code, torque makes the rigidbody spin.
Angular speed of the rigidbody is limited to avoid potential problems,
EtcâŚ
They have some tech demo in steam, tire + suspensions works so good and smooth.
Indeed FGear is the best vehicle physics solution right now but the devs donât seem to be interested in promoting it or making progressive improvements. Thats not to say it isnât production ready but thereâs much more that could be done to advance with the times (think GT to stuff like carx). Maybe it isnât a worthwhile investment for them but Iâm sure if they put as much effort as the guys at Rtunes are putting, itâll be worthwhile. That being said, Iâd love to see the devs implementation of drifting.
Well, about development and motivation i can understand, FGear was released in 2019, (7 years ago) the other is from mid 2023.
No idea about their promotion skills but i think they really did progressive improvements, bug fixing and added requested features from users(Thanks!).
I mean, with last update(New formulas and bug fixes) + deactivate symmetry + playing with Tire MF6.1, (which is another world to dive in) getting finally something that works in all scenarios in terms of behaviour.
Also i think Yunus is a soloDev for the plugin?
Btw, if i remember well, the big update(Still no ETA) will be the last(besides any bugFix), and done.
FGear 2 not confirmed(AFAIK), but if happens he said will be a completly rewrite, that based on existing and new features + time left to work on plugin probably nothing until 2027.
But if done correctly, common issues fixed, proper body-tire collision, maybe deformation, etc⌠he can perfectly sell it for 200-500$.
1 Like
yes, I am a solodev and this is actually a hobby project. I mean the average income is about %0-5 of my overall income so Iâm doing this out of personal interest not for money.
the amount of time needed to create a cutting edge vehicle system is sth. I can not afford. the math, the feature set, performance, limitations and making it all user friendly is no easy task. even if I do that and sell it for a higher price then people will expect a more comprehensive support model which will take more time and at the end of the day I really donât think you can make a living out of this unless you do business with some car/simulation company. and if you do that they wonât let you sell it on a market.
for the last couple of years Iâve mostly solved bugs and tried to add small features that wouldnât take much time. there is more to come but the scope and the context is not clear yet. a more precise drivetrain model and tires with proper collision etc. are all on my list. they may come with a big update or piece by piece or never happen if I fail to accomplish. I keep working on it from time to time thatâs what I can say for now.
6 Likes
I wish UE Marketplace (or Fab nowadays) has some sort of recurring payment to the asset author from the users who continue using the asset for years.
This way, it is financially comfortable to dedicate time to the asset, resulting win-win situation to both parties.
Having said that, FGear is definitely excellent in term of supports, features and bug fixes. Probably, the author should release a new fab plugin named FGear2 lol - new payment will come in from the existing user of FGear.
@lazybitgames Im checking the suspension and wonder if there is something more wrong.
AFAIK, âsuspension tire penetrationâ is to be used when it compresses more than it limits. But seems even when still not compressed(vissually) it clips the floor too Âż? This images are from same video, same landing.
The widget on the bottom-right says compresion is at max, but in first image visually is already under the floor.
But enabled or disabled, this happens on landing, it penetrates fenders, ground or both:
Video when i go frame per frame before the bug to check how suspension and wheels react:
Im on 5.7 with last update. Is this ânormalâ inside the bug we are talking or maybe there is another thing wrong? Or somehing is making even worse?
I have also âSuspension Hard Contact Scaleâ to 0.2, update 480hz, convex casting, etcâŚ
I tried with FGearExample and the FWD car just in case and problems are evident as the previous ones.
Still doing some tests, and i dont remember if you replied to this but for suspensions the calculation pre or post physics are not relevant? just to be sure and discard.
Btw, even on the plugin for enterprises it happens, just a bit but does, with the improvement that it never clips the fenders(no matter height or speed) but the ground. Trying the max clipping, 1 & 2 taking the ramp, 3 image on landing.
From big height (like 400m):
-
But found in FGearExample, the sportcar was very good handling this issue and after checking, realized it was due the bigger FGearCustomCollision
Taking the ramp is mostly perfect, just the rear clips a bit. On landing front perfect due guess it colides with the chassis collision and on 4 wheels landind again clips just a bit.
So i wonder if maybe adding joints(physic constraints) to each wheel + some collider, probably one that fits on the rim not the entire wheel, so the rubber may clip but not the rim so it can âfixâ the issue?
it seems there is a single frame latency so you can see it happen even if you uncheck âsuspension tire penetrationâ. I guess using joints wonât help, joints can bend and there will still be a delay, you can quickly try with the FGearSuspensionConstraint component.
I have tried to add colliders to the wheel with the unity version(itâs difficult to do that with unreal btw) and it still happens unless you activate CCD. adding colliders has its own downsides and itâs not a silver bullet solution.
I havenât worked on this for long but a perfect solution may not be possible. using colliders with CCD can be a good option. or it could be possible to let the visuals move separately so the physics will penetrate but the visuals wonât, it happens for an instant so it shouldnât be a problem but itâs no trivial solution either.
It depends on speed and how much falling, issue can happen in more than one frame.
Is more evident when you land on plain ground instead of a ramp due is more drastic.
Check this one, around +4 frames lag until get as it should.
Tried mCompressRatio & mCompressedLength always instead of âif (mHasContact)â at suspensionUpdate, but no improvement afaik.
Im thinking in some âOnRampâ or âOnLandingâ vehicle state to handle this cases.
On air, after the ramp, it gets colliders, on hit the ground and car stabilized remove them.
No idea if also some âOnWheelsClippingâ is possible to detect.
Another idea is get the compression speed, if bigger than X > Do Fix.
Btw, guess one of the first things to test is add colliders to check what are the real cons.
suspensions react to penetration after the penetration happens that is the origin of the problem.
if you run the physics at 1000hz for instance you can hardly see this because the reaction time is much lower then.
I guess the reason that it takes a couple of frames is that the vehicle keeps moving so one step of correction can not resolve it.
it might be possible to fix this with some kind of prediction, iâll give it a try.
1 Like
Btw one way to mostly fix, is set compresion damper to 40000.
But it removes the nice suspension bouncing / chassis swing:
-
Another thing is that with normal damper values, RideHeight(mCompressedLength) gives negative numbers, and in theory it should be always positive, 0 to up+down travel.
In this video, with 40k compresion damper, RideHeight keeps always positive.
So another idea can be, on Landing/CLipping/Falling/compression speed or whatever, retrieve the fall speed too, increase the compression damper based on them so is only used in that frames and only as much as needed instead of 40k always to adapt to the problem.
here is a quick test with predictive clamping, the first one is without the fix.
the fall speed is so high even the physics collision fails.
this is with unity version but iâll also try it with unreal soon.
1 Like
No way!, that Unity car config needs to be wrong, in UE i set the car at 40 meters with near double gravity and car body (FGearCustomCollision) never clips, with and without CCD.
Hope the clamping is per wheel and takes in mind no plain ground (ramps, etc..).
The other thing are the car fenders, the XVP plugin is what does perfectly no matter falling speed, but they use joints.
I can easily make it pass through the floor in unreal, you just need to apply force downwards and make it fast enough. also unity and unreal has different physics engines so we canât expect the same outcome for all cases.
unfortunately my prediction approach doesnât work for ramps, it only works for falling cases. using joints means you have rigidbody wheels so you can prevent it with CCD. even if we get rigidbody wheels in the future I want to keep the existing raycast approach and solve this somehow.
1 Like
I think I have a possible fix for this penetration issue. itâs not %100 accurate but looks much better. it predicts based on the vehicleâs velocity but there are some quirks too.
in unity it works the best without CCD, it becomes a bit weird with CCD because it messes with the velocity calculation but itâs still better then current state. without CCD itâs almost perfect, most of the time the penetration is zero.
unreal case is bit more complicated. even if I apply the same code in unreal there are often 2 frames of latency with the animation. itâs possibly due to multithreaded nature of the engine. when I set the tick group of the vehicle to âpost update workâ then the latency comes down to 1 frame and thatâs the best I could get.
@Davit_Masia if you wanna give it a try drop a mail and I can send you the code and instructions.
1 Like
That looks so good! also will depend how much the colission of that red car is helping, but yeah.
I realized that seems the wheel adjust up/down to fit the floor Âż? like maybe calculates the hit floor higher than it should, then fixes in next frames?
I will love to test that, just im busy rn, btw, having in mind what you did in just one day experimenting i can wait to solution gets more refined then when i get time will send you an email and i will do a deep test on my side.
@lazybitgames Is there any problem with EnhancedInput for steering in gamepad?
Im on 5.7.1 and just moved to the new ones, all configured and working, but for some reason when steering to the right full and drop, it does slowlly and when goes to center always does like a 1-2 steer not 0, if i do to left it does fine.
On legacy we only had the inputRight set and al worked perfectly the steering. Now due this we set both, left and right, but the problem still there and worst.
I think i tried all combinations, Also wonder if the Modifier Dead Zone isreally needed in EnhancedInput?
Btw, keyboard works fine on steering, it fails on gamepad, this is my config:
Anything wrong i should change Âż?
Edit: I tried your FGearExample, the red car that have EnhancedSetup but is not configured for gamepad only keyboard. Can you try configure GamepAd to see if you have same problems?