Have some problem that don’t know why, but at some time after doing stuff in the editor, the skidmarks, smoke… not appears when try to play the game in the editor. Any idea what can be?
i didn’t hear such issue before but it could be about the way unreal works with component settings. when you change a component parameter, the engine destroys the component and recreates it with the new parameters. may be the effects component has an issue with that but i can’t say for sure, could you tell me a couple steps to recreate the issue or does it happen randomly?
It looks randomly, since i posted i not had again the issue, but if happen again i will check the effects or remove/add again to see if fixes.
Btw I detected something weird with the skidmarks not matching the tyre, so i enabled gizmos:
When more speed, more difference between the real visual tires and the physical ones. What happens? It does in all cars i tested. I thought maybe was something i edit so i downloaded the FGearExample and same.
This causes the skidmarks not match the visual tires and other collision stuff due wheels are on XYZ due speed, but on collision it goes to the correct ones and if there is an obstacle it kicks the car to the sky.
So, why this happen? Anyway to fix this issue?
Edit: This is a Plugin bug or PhysX related? I mean, maybe with chaos it does better ¿?
it’s hardly a bug, if you try to draw a debug line from the vehicle actor location you can see the same delay.
we use functions from DrawDebugHelpers.h like DrawDebugLine, DrawDebugSphere etc. and it seems that this kind of delay happens(not sure why). the same goes for the skidmarks, the mesh generation might be delayed for a frame.
i don’t think its related to the physics engine(we fetch locations from both physics and bones), using an extrapolated location might work, i will try to come up with a proper fix and let you know.
So if i understood you well, the physical tyres on the car are placed OK, is just the gizmo who has that delay? Then i guess i have to find why that happened on that collision, my second suspect are the suspensions.
Then the gizmo and skidmarks have the same delay, due skidmarks are placed correctly just in the center of the tyre gizmo.
physical locations are correct.
i’m not sure what kind of collision problem you experienced but we have seen issues with spline meshes but the problem was not about fgear.
gizmos, skidmarks seems to be inherently delayed, we will try to find a fix for that.
Hi @Davit_Masia
1 - Draw debug function works slowly but physics is fine. Please don’t mind the delays.
2 - About skidmarks, you can type smaller value to “Skidmark Min Distance” in FGearEffects component.
3 - I don’t know why the effects disappear after a while. maybe it gets deleted at garbage collection time. Did you type UPROPERTY when defining the component?
Ok thanks. And more than one day without get that effects error, i guess due how i do now all tests.
Now, im trying to fix/improve another behaviour on wheels but not sure the best way.
I want to achieve this:
https://imgur.com/RysFCOT
When the lateral camera appears you can see the car brakes, turns, goes back, then start to go forward and all the time the wheels rotation are full due accel.
Actually trying to do the same, but if the car goes back the tires rotation too, stop and then go forward, instead of go forward all the time due accel.
https://imgur.com/EQmO931
You can see there is a moment the wheel rotation go back and then changes to forward.
Ive been doing tests and seems with mass 1 on wheels does the trick (until certain negative speed) but then the driving changes completly as it should and needs a reconfig for all.
So, wonder if there is a better way to achieve that ¿?.
Last idea, due is mostly on handbrake, is add another edit in the core to set mass to 0.1 on handbrake, then on release lerp to default, so be able to accel while goes to default without tyres rotates backwards.
You can try disabling ‘Allow Wheel Rotation Against Engine’ option but it might be undesirable to have it permenantly disabled.
Not worked for me, the wheel just stops, then, when it can, starts to go forward when it should be rolling forward all the time. I guess i need to do something related with friction but dont know what can be the best aproach to not mess the entire config.
you might try having higher torque at lower rpms and/or some trick with the tire mass.
i checked the source code and it’s kind of a design issue that wheel speed is strictly tied to ground speed and changing that code can be dangerous, it requires a good model to behave better and a lot of testing to make sure everything works fine. i added this to my long term todo list but do not depend on me, i may not be able to find a better solution.
I see, thanks for the reply i will try the torque/rpms too.
Btw driving around 90% as desired, are just that small issues that takes too time to get done.
Edit: Same with the R gear. If i go R, on press accel it should put the 1s, instead the R speed decreases, sets N and then 1s. Hope to find the way to achieve a good combo for all and keep the actual driving feeling.
Edit2: Doing some debugs just realized that when you accel in R gear, it really triggers the braking… then on 0 speed, set N then 1 and then triggers the real accel. Im gonna do some experiments.
1 Like
Well it looks i achieved the behaviour, still testing but looks promising.
At the moment the condition only triggers when you accel if car have X negative speed with:
“mLocalVelocity.X < 0.0f && mAccel > 0.0f”
That is when most is needed, so the actual driving remains the same.
Also added set gear 1 if you accel on reverse gear, so the 0.1 mass trick also works in this scenario.
You can see there is a moment i go reverse and press accel slowly and short times and the wheel try to spin forward no matter the car inertia, then on release it continues going back and wheels too like it should.
It may looks at some points the wheels are not moving if you see the radials, but check the letters in the tire. Just is too low mass for that low negative speed that spins too much that gives that effect.
Actually i set mass 0.1 to be sure, but if all tests are ok i will add some lerp and formula to change the mass from 0.1 to 1.0 max in negative speed and lerp to default when positive speed or accel is released to give a smooth effect as possible.
I think the trick can be achieved on positive speed too and keep same driving, but in this case will need to have in mind:
throtle force 0-1, rpms, mLocalVelocity.X… and some kind of “SpinWheelFactor” so 0 is like default, then on higher values you set how much spinning effect want in the wheel, if you add too much then wil look you are always in an ice road.
2 Likes
Finally i found the collision bug and the way to trigger it always.
It looks if the wheels surpases some object it tries to jump/push out, which kicks the car to the sky.
It does similar with the physics body collision but i fixed with this:
Now on high speeds the car not bounces like a ball. I set 0 to be sure it works, the idea is leave at 0.1-0.2 or similar.
But no idea how to fix this on wheels to avoid this:
To trigger always the bug i did this, to be sure the wheels contact to the mesh:
Is because if the collision is tight to the car for good collision and if you collide on high speed on steer, sometimes the wheels reachs the mesh and kicks the car to the sky.
In the object properties i saw something , not worked, no idea if i can set wheels as “character” to be able to use this? Is possible? Where?
So, if im not missing something and this is how FGear works, i ask for some option in Fgear Vehicle->General to tell the % a wheel can step up.
For example in real life a car can go over some obstacle if it is around 40-50% the wheel radius, all depends of car throtle and friction with that obstacle but you get the idea.
Or in Fgear Physical Material to tell yes/no.
What you think?
this is how raycasting works, to avoid those cases you either keep the ray origins inside the vehicle body collider and/or modify ray trace settings in “GeneralSettings/Tracing” to avoid geometry other then the ground. you can have multi raycast to climb smoother but lateral climb is not possible, if the ray hits a geometry it will try to climb instantly.
Trying to improve the last driving behaviour, want to reduce the time to turn in this case:
Tried various drive assists for steer: in general, in arcade assits and on inputTranssmision but the unique thing that does what i want is increase the longitudinal force scale in front wheels.
Ok, but is applied always, and i only want that extra on that situation.
I checked ArcadeAssists code and updateTractionAssist gives that extra traction lng&lat but only on low speeds, the sliders on editor is set to max 50.
So, i need that extra traction working on any speed, in my case only longitudinal in front wheels and applied only when car steer/rotates due inertia to one side while you steer+accel to the other side to reduce that time.
Also add the car speed% to the formula, due on low speed you will need less extra traction.
But no idea how to achieve that. Suggestions?
traction assist could be used for slow moving offroad vehicles, not useful for your case.
you want to activate this assist in a specific case which involves finding whether the vehicle is rotating due to inertia. that sounds difficult since any external force could cause a rotational velocity. you could try activating while rotational velocity and your steering direction are in opposite directions and also you can take understeering(check updateESP function to see how it can be detected) into account. if you are not understeering then this effect may result unwanted wild steers. you can use lateral/longitudinal slip values instead of using car speed, they are calculated from local velocity vectors. finally look out for multiple assists activating at the same time, they can generate forces eliminating each other and/or generate chaotic results.
This mostly works, at least is a start. I need to find a better variable to get the angular velocity / rotation force to one side… dont know what can be the best.
float mAngularVel = FMath::Abs(mBody->GetUnrealWorldAngularVelocityInRadians().Z * 100.0f);
if ( mHasContact && mAccel > 0.0f && mAngularVel > 100.0f)
{
mLngScale = FMath::Lerp(mLngScale, 4.0f, 0.01f);
}
else { mLngScale = FMath::Lerp(mLngScale, 3.0f, 0.05f);}
The bug is when the car not rotates( mostly stopped) but clearly have forces to that direction, but is something. Any idea to test?. Also still i need to add the mCurrentSteer condition to limit more to the case i want.
Edit: With the steer case:
float mAngularVel = FMath::Abs(mBody->GetUnrealWorldAngularVelocityInRadians().Z * 100.0f);
if ( mHasContact && mAccel > 0.0f && mAngularVel > 100.0f)
{
if ( mCurrentSteer > 0.0f && mBody->GetUnrealWorldAngularVelocityInRadians().Z < 0.0f ||
mCurrentSteer < 0.0f && mBody->GetUnrealWorldAngularVelocityInRadians().Z > 0.0f)
{
mLngScale = FMath::Lerp(mLngScale, 4.0f, 0.01f);
}
}
else { mLngScale = FMath::Lerp(mLngScale, 3.0f, 0.05f);}
So if angular is negative and steer is positve or opposite then give the extra force to steer. Is not 100% but getting closer.
even if the vehicle is not moving tires always generate forces, it’s how the simulation works, there is no sleep mode, so you need to filter those when the vehicle is stationary or slow.
Any idea on UE5 release? (do you have a download for the current test version)