Static mesh support: Would improve implementation and iteration greatly, Trying to set-up the a vehicle skeletal mesh in blender, set up the animation blueprint, reparent it, and having lot of crashes, then having the weels spin in strange ways, was the most painful thing to learn as a noob, i was tempted to change the vehicle component several times because of this, but the Fgear Physics felt always much better than the rest that convinced me to stay. With that said, if we ended creating the vehicles with their static meshes probably we will need to have telemetry or a tool to keep in check the distance between axis and wheels to keep it precise and in check since it affects the vehivle handling so much.
Effects is a big plus, specially to start using the current particle system that have a lot of documentation and assets available.
The physics surface support in my opinion is a pretty big feature, (im inclined to do something offroad with exploration) and having the grip and effects support integrated is great, if it keeps developing to enable easier and deeper implementation for things like more complex effects, terrain deformation would be great.
The rest of what you specifically list escapes the scope where i can really contribute an educated an opinion, im restarting a prototype so probably will have more ideas in a couple of weeks.
In my old prototyping i found some terrain penetration in jitter that never managed to completely solve in kind of big landscapes (4km square) but never managed to have it behave just right, specially with convex wheels
No UE4 support needed. Checked others updated plugins and they already dropped it.
Same Effects but niagara for new purchases. Polished if FGear 2.0.
About static mesh support, seems is the correct path now, so:
If means redo lot of things / effort:
Big update = Keep actual skeletal system
FGear 2.0 = Static mesh approach
About fixed timestep support, not sure about this, but if still relevant to improve physics simulation yes.
OTHERS
Probably remove mapping legacy due is gonna be deprecated, only Enhanced Input.
WISHLIST:
Turbo / Anti-lag system, which already requested, due RX cars have them based on gear ratios and RPM.
Some workaround / fix for the rev limiter thing we were talking about in drifting/Âș180 cases.
A proper ABS (Pulsating, not faking) and correct Anti-Roll bar system.
EBD system.
I did my own one but not 100% accurate. What it does is modulate the mBrakeTorque based on getSpeed()*mRadius, per wheel and axle comparing their ratios. So instead of brake all wheels with same braque torque it changes to fit the needs of each wheel.
If more speed = More brake Torque in that wheel, if less speed = less brake torque,
Helping all wheels to keep similar speed and avoid locks due too much brake and keep stability under braking.
But seems a good one needs to take mCurrentLoad into account too and being integrated with ABS for full accuraccy.
With all that, i think there is more than enough for a FGear 2.0, imo, instead of big update.
thank you all for the feedback, iâm taking notes and prioritizing based on several factors like difficulty, overall value etc.
I also want to keep unreal4 support for a single reason. I have to do the development with the minimum supported version and ue4 is easier to work with and the editor runs much faster. for some reason hot reload and live coding doesnât work in my plugin project so itâs time consuming to restart the engine anytime you make a change.
there are already some surface presets like asphalt, grass and ice and they modify friction + they add some pseudo drag force to slow down the vehicle based on roughness parameter. I donât prefer creating separate tire models for each type of surface, tire models are hard to tweak and harder to find proper parameter sets. my only plan about this topic is to try to get rid of fgear specific physical materials and allow the use of native physical materials.
there will be more options for the suspension geometry, this is already improved on unity side.
there is also some sort of wheel collision implemented on unity but it has some limitations. Iâm not sure if that will be possible in unreal but I will try replicating it. itâs a tough task and hard make perfect. anyway leaving a video below.
a turbo charger is planned
g-force calculation is planned
niagara support is planned
damage is system is not planned right now
force feedback is also a difficult topic, I did try sth. simple in unity before but it was too basic. maybe in the future.
static mesh support may complicate the code a bit more and I think it can be delayed for upcoming versions after 2.0 but I havenât decided on this one yet.
I want to keep the legacy input until itâs removed, itâs easier for beginners.
realistic ABS and ASR are in the works, they seem fine at this point, more testing will done.
EBD and torque vectoring stuff are in my list but lower priority.
What else would you add about force feedback?
My game supports force feedback steering wheels, and I was able to integrate it with fgear without anything extra just by recovering forces from the wheels.
Are you thinking of some kind of output interface to recover the useful forces to be transmitted to the force feedback?
my attempt was also sth. similar, recovering based on wheels travel but it felt terrible compared to some games that I tried. I wanted to put some decent default effect but I wasnât satisfied back then. as you said my plan is to generate data that could be directly applied to the feedback device.
We tried Niagara for skids, ribbons and decal render and none worked visually well in all scenarios, so we ended doing our C++ approach.
The main problem with niagara are the slopes, they get stretch, deformed or twisted. We tried various combinations on the niagara like face mode and other stuff, same in blueprints to detect the hit point and the slope , using normals, etc⊠and besides almost got fixed it also makes different the ones on flat surface. The C++ approach fixes all bugs except the floating skids, but since even FH5 suffer from this no much problem.
If you or somebody achieve skidmarks using Niagara that works well in all scenarios like slopes,etc⊠i will be interested to know how the hell the fix is.
Hey, my reply was to B62FSDJ62315, âhow can I get a Niagara particle to work for the skid?â.
EDIT: Also we use procedural mesh like FGear for the skids, seems the best solution. Just we use more data for fading and intensity for a more realistic visuals.
One more important suggestion that I forgot to mention earlier: the system needs a more realistic engine braking and internal resistance simulation.
Currently, if Iâm driving at high speed (e.g., 200 km/h) and shift into reverse, the car continues to roll freely as if it were in neutral. A counter-force only starts to act once I actually begin to accelerate in reverse.
This is also very noticeable on inclines and descents. While the Hill Holder helps a bit by simulating automatic car systems, the physics should naturally include engine compression/drag to hold the vehicle. If the car is in gear on a slope and I release the throttle, the internal resistance of the drivetrain should prevent it from rolling back like itâs in neutral.
It also happens in FH5, you can see clearly the smoke inside the car. Example:
There are two approached to avoid that, a collision mesh or smoke particles in niagara via GPU and using distance field to destroy or move them. Btw, from our tests not always ends working well and also is a bit expensive which depends in how much smoke particles spawns.
So we leave it for now, we just made the smoke less dense, less lifetime and small to reduce that effect and works for now, will return to fix the issue in the future.
Btw, if somebody fixed in a good way im interested too to know how.
I will recommend hire a sound designer that can do the sounds and FMOD implementation in UE, i did it and it saves lot of headaches. I hired Skril time ago, has lots of car audio assets in FAB, no idea if he is still available, this guy:
Some of their assets comes with FMOD projects already setup like this one:
hello davit! , thank you , i use fmod without problems , The trick is correctly detecting the physical materials to change the sound with FMOD. Iâve worked with the engines in integrated FMOD without any problems, but what confuses me is how to change these sounds. Also, the cabin noise from the tires sounds the same as outside, which detracts from the immersion. Thatâs why Iâm asking if thereâs a way to integrate it with FMOD to provide better sound immersion.
hello david this is my solution , use a camera depth and fade depth , when you are on the first person the smoke dissapear for the camera fade depth and the fade depth makes the mesh blend with the smoke , very cheaper solution and fine too
