What is this?
&stc=1
I would say motion blur gone insane x) the wheels spin so fast that the motion blur is weird, especially if you pause the video, plus at that exact moment the wheel had bounced too much on a bump on the terrain. It is why I set a angular velocity on the visual wheels. you can set it to a lower value to reduce this effect.
This is a problem that happens with all vehicles, no matter how I implement them. its only a visual problem, yet if anyone knows how to get rid of it, it would be nice.
@JX53mb So I tried putting this in the advanced vehicle template (migrate, removing the default kart BP, remapping the input etc) and the vehicle gets all crazy as soon as I hit play, the wheels almost detach from the vehicle and it flies away pretty much like the Epic Kart used to/still does sometimes. It works fine on the project you uploaded, any ideas? 
@DavidNSilva, the project uses custom trace channels.
OhâŚdidnât knew that. Iâll try again now with the custom channels Thanks 
Edit: Now itâs working Thank so you much @. I must say itâs the most stable vehicle class Iâve tried yet, Iâll probably convert it to c++ and end up using it if the engine vehicles are not fixed.
Try it on a ue4 landscape, I dare you Just put even a default landscape there, no hills, nothing. It takes 10 seconds to do that so thereâs no excuse.
Ohh **** xD okay I take back what I said about landscape, you MUST use a static mesh terrain with complex collision as simple. x)
Were anyone able to get rid of the hitting the curb problem? the front wheels fly away too much when approaching the 50km/h mark as someone previously said. Realistic or not is just too much, I would understand that would happen at very high speeds but at 50km/h climbing a 10cm curb the car should climb on the curb and not bounce around. Imagine if this happened on any of the gta gamesâŚit would be crazy. I tried all sort of settings and constraints but to no avail.
I believe that at this point the problem is that the tires do not absorb any of the impact, they are like concrete, I do not know if I can fix that. Still experimenting with it.
I see, I was trying to constrain the rotation /speed of the body mesh and also tried to constrict z speed of the springs but didnât work well enough. is there some physic setting to resist impact? if there is something like that we could increase it based on speed to stimulate the tire absorption maybe? I tried messing around with the wheels mass but didnât seem to make a difference.
Imho you need asymmetric dampening and limit on maximum force of the spring.
Why dampeners are important:
Some gritty details on why effect of dampener needs to be asymmetrical
itâs basically to avoid a violent forces from rapid compression of the spring when wheel hits a bump and prevent rapid spring expansion when you drive over the hole in the road.
The higher velocity of the spring the higher dampening force will be, depending on direction of velocity you can set it to 25/75 (this seams to be a typical proportion in regular cars).
thanks for this video full of valuables informations.
so if we simplify things as much as possible, the harder something hit the wheels, the higher the damping will be, right? so we could make the suspension damping scale up with the vehicle speed. the guy also says that the tire absorb some of the impact as well, wich I could replicate using a sphere trace, and apply velocity to the wheel mesh with collisions disable, to prevent the wheel from getting in the ground. Doing this would simulate tire pressure.
does that seem like a good idea to anyone?
yes I was thinking doing something like that after watching the video, I am not sure about using the hit event however as that is constantly triggered by ground contact. I am thinking getting the z velocity of the spring each frame and then increasing the damping value accordingly, as for the tire pressure it would be simply a constant value added to the damping, the guy in the video even told the tire itself is kinda like a spring and dampener so why not merge the too in our case. however this is all theory I didnât put any of this to practice yet.
I think this has to be applied on a per spring basis because we can have an impact with the two front wheels and the rear wheels are left untouched,⌠and we raise the damping for the four wheels things might go wrong.
Hey JX53mb, just wanted to pop in real fast and say thanks for sharing this cool feature with the community. I shared this page with some of our vehicle physics developers and they had some advice about what you had asked me about:
PhysX doesnât support cylinder sweeps, and currently donât have plans to add it. However, you could make a cylinder mesh with convex simple collision and sweep that yourself.
If this is a sweep, you could include the components to ignore in the sweep params.
I hope that helps, let me know if you have questions.
BoredEngineer suggested this earlier as well on this thread:
I also recommend tracing/sweeping over constraint setup as you canât make a fully constraint based car setup like this stable with ue4 (unless your vehicles only travel at slow speeds). I already briefly mentioned constraint setup has issues and Iâm sure whoâs worked for a while on vehicle physics with physx will agree to the underlying issues.
Iâll list few of the biggest ones here:
- Constraint based vehicle will be unstable at high speeds since physx canât solve it properly anymore. You may be able to drive on somewhat leveled ground at high speeds if you just drive a straight line but thatâs not what games do.
- Even without landscapes, your vehicle will not have reliable grip to the ground because on every small bounce on wheel, you loose grip, same thing would happen in real life if you just put full metal wheels to a car. If Physx will provide more reliable way to solve these collisions in the future, this might change but it still wouldnât still be ideal.
- You canât model tire friction properly on constraint only approach. I see you rely on physical materials on this but they were never designed to cover this kind of use case. You can preset one friction value per tire but you canât modify it at run time on blueprints without swapping the physical materials around. Physical materials donât make a very believable tire friction even if the contact points kept stable. With tires youâd want this kind of setup: https://pavemaintenance.wikispaces.com/file/view/Figure_2_pavement_friction_vs_tire_slip.jpg/207423378/Figure_2_pavement_friction_vs_tire_slip.jpg. To explain that bit more, your tires usually grip well up to a certain point and then when they lose the traction the force they can put toward the ground drops as tires just slide. You canât model this properly on physx physical materials and is one reason why you either have grippy tires or car on full drift mode with lower friction value on a physical material. This is especially an issue at high speeds as car just rolls over if you have grippy tires when in reality grip level would go past threshold and start sliding instead, resulting in a just a spin in most of the cases.
Since your car is BP only, the hacks that are done during the Tick (to make it more stable) will be framerate dependent (remember Ticks are run at rendering speed, not at fixed intervals). This means fixes will work differently if player runs game at 20fps or 100fps.
Traced wheels have their own share of issues to solve but most of them are solvable. I admit itâs not as easy approach as just putting together a bunch of colliders with constraints as you actually need to solve the grip and corner cases yourself. But this is also a huge benefit: you actually have control on how the friction gets applied, unlike with pure constraint+collider setup.
Worth mentioning though, you canât do tracing/sweeping for suspension on BP only project reliably because the already mentioned variation on delta time on Tick, youâll need to do that during substeps which requires at least some c++ code or a plugin.
Some additional observations on this project:
- You donât have antiroll. One reason for cars rolling over in this project is the lack of anti-roll bars, youâve only setup the COM to the ground level to prevent that but that is more of a hack and will lose itâs effect at higher speeds.
- The way you do fake wheels is not good for the simulation. You add additional constraint and mass to the simulated wheels physics sim which can make it even more unstable. Your fake wheels are for visuals only, you wouldnât want to do any form of physics on them. Instead of doing what you do now, you could just disable the physics sim on fake wheels, attach fake wheels to suspension childs without constraints so theyâd always follow the suspension. Then rotate the wheels on code, that way you can also control the visible rotations not happening too fast for motion blur.
Your engine sim logic has fundamental flaws in it:
- You apply more torque at wheels at higher gears, what happens in real life is exactly the opposite.
- Each gear has itâs own torque curve. Cars only have one engine that works with the same torque curve regardless what gear you use.
- You force RPM to rise at constant speed (for each gear) regardless if your wheels have grip or not, which means engine sim is totally decoupled from actual cars behavior and it canât handle wheelspin properly. Do note that in real car, when clutch is gripping, you have fixed connection between engine rpm and wheel rpm through transmission and differential (with manual gearbox).
- You limit wheels angular velocity directly with engine torque value, Iâm guessing this is some attempt to make a traction control but it doesnât make much sense in the end.
- The way youâve implemented engine sim leads to a bug where you can occasionally loose all traction on some bumps and your car just stalls. Since engine sim doesnât know anything what happens to the wheels grip, it just keeps adding more torque to the wheels which just keep spinning wheels even faster and they canât grip anymore. When that happens, you have to wait until the cars speed drops low enough for the car to shift down and find a grip again.
- You control automatic gear changes by vehicle speed regardless what happens on the engine or wheels.
- Engine setup is based on magic numbers that need to have retuned on each change, even if you change tire friction value.
I must disagree here with you @0lento did you actually tried this project? The only thing that is left unsolved (and itâs a deal breaker) itâs the current suspension problem. The Fake wheels simply exist because the physics wheel spin way too fast, that is the only reason why there is two sets of wheelsâŚthe op explained this a couple of times before. The hacks are Not framerate dependent, the hacks use Add Force which is multiplied by deltatime by the engine code. Despite the current suspension problem this is 100x more stable than the default vehicle class ever dreamt to be (even before the 4.14 âfixâ )âŚI can barely drive that for more than 10 seconds without it starting flipping uncontrollably and doing all sort of weird things. I think this project not only is tons more stable but also feels very goodâŚeven the vehicle class feels too âarcadeâ and not like a real vehicle. I would rather use this then the current vehicle class (even before 4.14) anyday. Unfortunaly with the current suspension problem none of the solutions work for me.
Sure, how else could I have given feedback from the projects issues? Iâm not here to pick a fight or rain on your parades. Just pointing out what causes issues with this kind of setup.
OP has explained that fake wheels are there to fix the motion blur issue and nothing I said on previous post says otherwise. I did check his project and he does use physics simulation on fake wheels even when he overrides their angular velocity from BPs. They have mass and they are attached to the real wheels so they take part on the actual simulation (they add mass to the suspension and additional constraint to solve) - which isnât right way to do it. Do note that I told more proper way of doing it too.
You kinda missed my point. Add Force itself handles the deltatime variation (although itâs not perfect but that would be a topic on itâs own), real issue is that if you do quick changes to the physics on each frame. You can only react to the changes only when Tick occurs. A good example of this is if you handle for example suspension on Tick: If game runs 15 fps, you can get new data only 15 times per second vs 100fps you get data in 100 times in a second. With 15fps, if suspension then is fully compressed, you apply full counterforce for the timestep of 66 ms. If the same thing happened at 100fps, timestep would be 10ms and youâd get a new data for the suspensions new position after that 10ms. With 15fps route, you have to wait 66ms just to realize that the suspension you tuned to work properly at 100fps now launched the whole car into space. Similar inaccuracies happen on anything you change on tick that alter the physics simulation, although the effects may not be as serious as on my example.
I think we all can agree that default physx vehicle isnât very good. Constraint based vehicle on the other hand is a lot worse on certain aspects so itâs not fair to say itâs 100x more stable (as it isnât). Iâve explained the reasons on my previous post but of course, you donât have to believe what Iâve written there, itâs just my educated opinion on these matters. For all others, be at least aware of the mentioned issues if you pursue this route.
@0lento Not trying to pick a fight either just peacefully discussing some pros and cons. I understand the point youâre trying to make and I agree that constraint based vehicles are not very good. but implementing a trace based vehicle class from scratch can be very expensive in terms of time and resources. we can easily attach a trailer to this and it works while the vehicle class⌠well you known. do you know some other readily available solution out there you recommend? Also could you elaborate on what I should expect if I go with this approach? the hitting rough terrain at high speed problem you mentioned did not happen on my tests (and I tried it on mountainous terrain at 180km/h)âŚof course hitting a 5cm flat curb at 50km/h didnât went so well lol
There isnât a solution thatâs quick and easy, but thatâs how things usually are on gamedev. Iâve been doing this for few years and just sharing here what Iâve found out myself.
Besides the suspension issue, just simply lack of control is one thing that is causing trouble. You can fix friction issue if you just slide 0 friction colliders (wheels) on terrain instead of using physical materials, but then you need to calculate the friction and wheels angular velocities yourself on code and youâd really want to do that at more predictable time steps than what Tick can offer. Youâd also want to use additional traces to check the connection to a ground so small bumps will not stop your traction (which leads to the vehicle twitching around, like seen on this project when that happens). This isnât as simple to do as the pure constraint setup as youâd then need to model all aspects properly, starting from engine. Then again, if one does all that, going to non-constraint setup isnât that far away anymore.
I didnât really mean like hills or mountains but things that are uneven and can make small bumps, like the curb you mentioned. Game levels are full of small details. Just try this vehicle on VehicleGame demotrack and youâll see what I mean. Besides that, constraints donât work well on physx terrain (ue4 landscape). If you use meshes, you have to use complex as simple and itâll become pretty expensive quickly. Do also note that even if your CPU can handle it, average players computer might not (unless you test it on a weak CPU yourself). Complex as simple can work if itâs just selected part of the terrain, like roads that donât have a lot of polygons.
If you carefully prepare your ground plane where you drive this kind of vehicle and donât go to high speeds, you can make it work. Issues at high speed is not only the bumps on meshes (which you can avoid if you do a really careful level design) but also the lack of control over the friction as mentioned before. And having things out of control is never a good thing on gamedev.
Slightly related to this topic, I recommend anyone working with physics to watch this talk: Designing with Physics: Bend the Physics Engine to Your Will. It doesnât give all answers to the issues on this thread but it may bring some insight why things happen like they do with physics engines.