Wheel Controller 3D - Customizable Three Dimensional Alternative to WheelCollider

The problem with sideways creep has been probably the biggest problem since the start of WC3D. It is due to the fact that the WC3D is limited to FixedUpdate() tick rate and it works on physics-based formula which essentially
creates a reactive force for any amount of slip that happens. A too small force will cause slip and a too large force will cause jitter / jumping and as such the force must never be larger than required. Default wheel collider has this
problem too to some extent but it can be partially solved by increasing the update substep on the wheel itself (which is possible because default wheel is calculated in the PhysX itself), while the WC3D can not do that because it is bound to the FixedUpdate().

I am at the moment testing out some ideas but while improvements in that field will happen, I can never garantee that the vehicle will be able to be glued to the place on the sloped surface - as long as rigidbody and AddForceAtPosition() are used. Even the constraint option of rigidbody and the default wheel collider will creep over time.

Hope this answers the question.

 

I can imagine it is not easy, particularly with limited access to PhysX. Is there no kind of static friction that can be added or additional downforce when vehicle stopped/slow?

 

Any chance this works with Edys vehicle physics?

 

You could port it if you wanted but that might be hard since Edy is using a lot of code tweaking to make his vehicles behave with his current solution.

You could check out NWH Vehicle Physics (https://assetstore.unity.com/packages/tools/physics/nwh-vehicle-physics-107332) which a vehicle package made on top of WC3D and 50% off at the moment.

 

Ah yes I've seen this. I actually purchased it I'm just wondering if it's possible to use Edy's with your wheel collider as some of the vehicles I have are a little more suited to Edy's physics and are already set up with it.

 

Hey @NWHCoding

1. I observe little time delay play mode, especially when I play in maximize mode.
I mean Car reads my command after some time, say 100ms.
What changes I can do so that it reads instantly?
FYI
UNITY project-> Quality->Medium
ISLAND Scene, Windows, i5 processor, 8GB RAM, 2GB AMD Graphics.

2. Can I record values in a .txt file to plot in matlab? (car coordinates in world space, speed, acceleration, longitudinal/lateral Slip, yaw rate & lateral/longitudinal tire forces)

3. How can I see telemetry?

4. My rigged car is jittering @High frequency ~20Hz on the standard terrain, what could be a solution?

5. Can we calculate the predictive stopping distance from related inputs we have given in 'VehicleController'. So that we can show at the screen in realtime ? Also a good data for AI

Thanks

 

Problem 4 is solved by changing fixed time step from 0.020 -> 0.017..

 

Hello,
to answer your questions

1. Desktop Input Manager uses Input.GetAxis() which has some smoothing built in. Replace it with GetAxisRaw() for no smoothing and more immediate response.

2. Out of the box there is no .txt writer but it can be implemented in a few minutes since it is quite simple, e.g. https://shanemartin2797blog.wordpress.com/2015/11/20/how-to-read-from-and-write-to-csv-in-unity/

3. vehicleController.metrics

4. Glad you managed to solve that one. In v1.6 there is a warning box inside the inspector to inform users about this.

5. Unfortunately not. It would be possible to calculate using physics formulas assuming there was no slip or any factors involved since the brake torque is known, but I am not sure how accurate such calculation would be since there is more than brake torque at play.

 

Thanks for quick reply
1. I will try this GetAxisRaw().

2. good info 'write-to-csv-in-unity'.

3. I can't find vehicleController.metrics. Can you give me!!

4. 'Warning box inside the inspector' is a very good idea.

5. Ok Then, I will apply curve fitting 'stopping distance' vs 'speed', after recording some stopping distance data points.

6. I checked steering.cs. I feel that, Ackerman can be applied in a better way. I mean, Ackerman angle correction depend upon, wheelbase and track-width of car. Have a look on the attached images, may be you like it.

Cheers..

 

@NWHCoding
And also, I saw the Telemetry Snapshot at your website. There is no Fx, Fy & Fz forces for each tire.
Maybe you can incorporate these parameters also in telemetry. For now can you tell me, how can I access Slip values for each tire and if possible Fx, Fy & Fz forces also ??

Thanks for consideration.
Have a good day..

 

They are not in telemetry but can be accessed through the individual wheels through WheelController API.

sideFriction.force (X)
forwardFriction.force (Z)
wheel.tireLoad (Y)

e.g. axles[0].leftWheel.WheelController.sideFriction.force or wheels[0].WheelController.sideFriction.force.

For slip the same but e.g. sideFriction.slip
I am writing this off the top of my head but should work as written.

 

Accurate Info.
I enjoyed your project. Everything working nicely. Quick response.
Superb keep it up..

 

Hey @NWHCoding

Could u explain me why are you dividing by 80, why not 90?

Sorry if my question is stupid.

 

Shhhh, it's a trade secret.
Actually that there is so that the value of slip would correspond to the slip graph from the reference graph I was using, without the need to resize the Animation Curve. This way 0.1 on graph equals 8 degrees of lateral slip. This way the slip curve stays normalized (x = [0, 1] and y = [0, 1]) instead of needing to stretch X to 80. I prefer all curves normalized and the only one that is not is the damper unit force and that is because the X (suspension velocity) could in theory be very high and the maximum is not known.

 

Ahh OK, Thanx for the reply.

 

I spent a few days on a prototype I had in mind for a while, but for the life of me I can't figure out why my wheel is unstable. Is it because of the angle? I tried to play around with ray count(I went even up to 2048 rays per wheel), tweaked time, the WC3D's settings but nothing worked, can anyone help me out please?

 

No, the resolution would not have anything to do with it, nor the other things you listed. It could (hopefully not) be a bug introduced with the newest version or setup problem. Could it be possible to share the scene via email so I can have a look at it as that would be the fastest way to debug. If that is not possible please turn on debug flag and gizmos and see what is happening there - for starters.

I was just trying to replicate the problem with the demo SUV by placing the wheel at the same angle as yours and lifting it manually of the ground - works as expected. One thing I would suggest is checking that ignore layers are properly set.

 

Sure, the scene is full of unnecessary crap at the moment but as soon as I strip it down to the bare minimum I'll send it, thank you! As far as I know the layers are set correctly, the bike's collider is on the "Scan Ignore Layer" and it's selected as "Scan Ignore Layers" on both wheels. However if I rotate the wheel even more the issue is way more obvious, when I rotate it so it isn't at an angle it works as expected

Edit: I tried to replicate it with the demo SUV, I rotated the front wheels 35 degrees and as you said it worked as it should, however as soon as I raise the spring travel above around .52 the same issue appears. Also for some reason it is floating above ground with these settings if it can stabilize.

 

Got the mail, I am on it. Most certainly a bug that went unnoticed due to a bit specific use case.

 

Hi, is it possible to make the wheel always attached to the ground?
It is due to that I wish the car will never jump up or flip over, I had tried that makes the length of spring is allowed longer than the max length of spring and if this situation really occurs then adding a force to car's rigidbody at the wheel's position. But I don't get it to work, any suggestion?

 

No, out of the box such behavior is certainly not supported. It is also a quite unusual request I might say - especially for something that is based on physics. Good news is that this was actually a bug in the early development (spring applying force in both directions) so I am quite positive that it would be easy to replicate.
What needs to be done to get such behavior is make a spring curve that goes from -1 through 0 at the middle and then up towards 1. Also, all the Mathf.Clamp() and Clamp01() that clamp the spring force between 0 and Mathf.Infinity and possibly Mathf.Abs() functions need to be removed - only 2 or 3 of those exist. All of this is inside WheelController.cs.
After that you will get the behavior that you need. No need to go over the max length - the idea is just to make the spring 2x the length it would normally be and apply the oppsite force of what is normally applied if the spring starts to extend too much (hence the 0 of the curve would be at or near the middle of X-axis and Y extend into the negative).

 

Hi, been using WheelController for the past week and have a couple of observations/problems:

1 - To use the 'visual' aspect of WheelController it seems like you need 2 types of wheel, one with no rotation for the left hand side of the vehicle, and one rotated 180deg for the right. Using the former for both sides results in the right wheels facing the wrong way.

I'd prefer to use 1 mesh for all 4, I guess with a boolean, or using the side enum, to rotate for the right side. I overcame the issue by manually setting the position and rotation from the variables offered by the WheelCollider.wheel class, but also applying a 180 rotation for the right hand wheels. This kinda worked fine, but unearthed the following problem:

2 - It also looks like WheelController is struggling to keep up with the rigidbody. When stationary or at low speed (< 20kmh) it seems to be fine, but then starts to fall behind and gets worse with speed. This happens in both my project and the demo project. The screenshot below is from the demo project, the vehicle is traveling at about 50 kmh. As you can see the green wheel gizmo has fallen behind the vehicle.



Many thanks!

 

Hello,
to answer your questions:

1) Well, this one is kind of expected I feel. What visual aspect does is exactly what you would do if using default wheelcollider - moves and rotates the wheel to follow the wheel collider. So of course it needs to be properly rotated and have a proper pivot. Of course, if this does not fit your needs you can always move them manually as you can with wheel collider. But if for some reason your model got shipped with only left or right wheels you can always just parent them to an empty object, rotate them and assign the parent object as the wheel.

2) No, it does not. It is where it should be but what you are seeing is just the debug gizmo lagging behind due to the fact that gizmos are updated in OnDrawGizmos() while the wheels are calculated in FixedUpdate(). Nothing to worry about.

 

Hello! How to fix that problem?

 

Hard to tell from the video but it is most likely one of the following:

• Incorrectly set up ignore layer (make sure that Ignore Raycast is also ignored, in newer Unity versions this has been changed to Ignore Queries or similar)
• Rim colliders seem to be smaller than they should, are you changing the wheel radius at runtime? If not you may have scaled something - scale of 1 is recommended.

Please check those two and if they do not fix your problem I might have a few more ideas. Or alternatively you can just send me the project folder and I will check it out.

 

Hello,
This Asset wheel controller 3D is compatible with mobile controls?

 

The asset is the replacement for default wheel collider. It has almost identical API with a few additional features added in. The vehicle controller that you see in the demo scene is for demonstration puposes and is only a few lines of code. While you can use it in your end product I would suggest writing your own - as you would with default wheel collider.
This is not a vehicle controller asset and please do not confuse it with one.

 

@NWHCoding Hello. I'm experiencing a impulse/step height issue when my vehicle goes over a small bump. My vehicle will somersault. I know this is called out in the doc. Adjusting the wheel settings helps, but nothing outright fixes it. I've copied the wheel/controller settings of the demo truck into my car, made sure the rim collider is on, collision and wheels layers match and all my ignore tags are all set properly. Raytrace variance made no difference. In fact I could sometimes reproduce the somersault with the demo truck, though it seems to happen more often with smaller wheels and shorter suspension. Any suggestions? Is there no limiter on this impulse?


Also shown below, the vehicle can get launched when on its side. You can easily repro this issue it the demo scene with no alterations.


Another issue I noticed are that collision volumes tagged as 'is trigger' still collide with the wheel. You can make a volume ('default' layer) with 'is trigger' and it will launch the vehicle into the sky.

 

@NWHCoding In regards to my post above (#228), are there no solutions to these issues occurring in the demo scene? As much as I like this wheel package, these issues are project breaking.

 

Hello,

starting off with the trigger thing, this can be quite easily solved by unticking "Queries Hit Triggers" in Project Settings.
There is also an optional parameter that can be added to the Raycast call named "QueryTriggerInteraction" (https://docs.unity3d.com/ScriptReference/QueryTriggerInteraction.html) if disabling it on global level is not possible due to project requirements.

As for the impulse, this has been fixed to some extent in NVP but WC3D is lagging behind slightly with updates (NWH Vehicle Physics uses WC3D for ground detection, and most of development is happening there). At around line 580 there is a calculation for spring.bottomOutForce and a float constant at the end (e.g. 0.025f) by which the whole calculation is multiplied. Default value for NVP is 0.01f but it can be reduced even more.

To explain: when the wheel encounters a sharp ledge such as the curb and the spring travel is actually shorter than the height of the curb the spring will go from mostly extended in one frame to fully compressed over one frame. In this case - in real world - this would result in suspension hitting some kind of stopper to prevent it hitting the frame of the vehicle itself. Since we are speaking about an approximation in discrete time a force impulse is sent to the vehicle from keeping the wheel going through the ground (since the forces applied to the rigidbody are the only thing keeping vehicle above ground). This force has been set to a way too high value by default and reducing it will help a lot.

Another thing that can be done is enabiling rim colliders to avoid sideways collisions with the wheel (i.e. approximate obstacle hitting the rim instead passing through). Oversizing the vehicle's body collider can help too and will have the same effect.

Hopefully this helps. I will be releasing an update for WC3D soon with the new features from NVP implemented - most notably the multithreaded raycasting.

 

Update 3.6 is on the way.

Changes:
- Implemented multi-threaded raycasting for greatly improved performance.
- Reduced bottoming out impulse force.
- Improved rim colliders.
- Other bug fixes.

Update has been uploaded and is waiting for approval. Expect it to be live in 2-3 days.

NOTE: To update to version 3.6 of Wheel Controller 3D, Unity version 2018.2.0 or newer is required. If you have older version update will not be visible.

 

Thanks for the update!

Question. I updated to 2018.2.0 for this patch. I've read that 2018 suffers from intervals of EditorOverhead spikes (100-200ms) when playing in editor, which I'm encountering. I'm noticing that the WheelContoller.FixedUpdate spikes (2.5ms spikes to 35.0ms) for a few frames after these EditorOverhead spikes occur. Is this normal?

 

I have never had such problems, but then I have been using 2018.3.x for the last 2 months. I have found this thread:
https://forum.unity.com/threads/editoroverhead-200ms.517261/
And it seems that some people have problems with this and Unity acknowledged it is a bug on their side so not much I can do there. But then, one person mentioned that disabling GeForce Experience solved the problem. Still, I am running RX580 so it could be the reason why I am not experiencing this - if it is related to nvidia.
Still, if you do not have the problem when not profiling I do not see it being a large issue, as long as it does not appear in builds.

 

Hey is there some trick to updating to the latest version? After updating my wheels don't collide with the terrain anymore, they just fall right through. On 2018.3.3f1

 

Nope, assuming the update did not bug out your project in some way. Could you please try importing the asset in an empty project and seeing if you have the problem then?
I have tested the package that was submitted to the store and there were no problems, and the other asset NWH Vehicle Physics had this update for at least a month now. Still, could be some bug so please check with empty project to make sure.

 

@NWHCoding I think I've isolated the issue actually - I'm assigning the wheel.visual at runtime as I spawn in different wheel/tire combos. I notice that you've moved the wheel initialization into an awake instead of start so it fails before I can assign it. Is there another way for me to set collider properties at runtime?

 

As a followup, I've now resolved my issue by unsetting the wheel visual completely and instead calling GetWorldPose on the colliders and setting my mesh rot/pos directly. Doing this however I find that upon harder impacts my wheels are clipping through the ground a bit, just during impact. I do have rim colliders enabled and wasn't experiencing this issue on previous versions. Is this related to my setting the pos/rot manually or would it be a result of the updated version? Any way to resolve that?

 

Hmm, there should really be no difference on setting them from GetWorldPose or using the visual field. After all, the visual field is supposed to be just the internal implementation of it. What you are experiencing is due to the changes to the bottoming out code as previously it would overreact and result in jumping vehicle. It was tamed quite a bit and calculation changed but I guess an option to set its intensity would be a good idea, since the behavior you are experiencing is the opposite of the previous behavior.

Go to line 600 where the spring.bottomOutForce is calculated and tweak the number at the end until you are happy. I will add some kind of slider in the future for users to be able to adjust bottoming force between the two extremes.

 

Yea this does it, thanks! A slider would be also be great.

 

Hello @NWHCoding I'm wondering if you can explain some of these numbers I'm seeing, I don't fully understand them. I'm trying to use the cheapest wheel settings possible (single ray/no rim colliders). From my understanding of the profiler, it looks like it adds 5 raycast calls per wheel. Is this expected behavior? I'm testing mainly on unity 2018.3, though 2017.4 seemed to show the same results. @NWHCoding

 

From your screenshot it everything seems fine - only one raycast per fixed update. I assume you have 4 wheels on a car and you have 5 fixed updates per one update which is 4(wheels) * 5(fixed updates) * 1(raycast) = 20. Note that for one update there can be multiple fixed updates and that is what the profiler shows.

 

hi there,
I hope someone can help me with this as I am stuck..

I am using Wheel Controller 3D and need the Camera Default Script to make the Target Look At an instantiated prefab
Does anyone know a line of could how to achieve that?

 

I am assuming you are trying to use one of the demo scripts for camera control from the demo scene?
Might I ask what the problem is?

Code (CSharp):

1. GameObject myObject = Instantiate(myPrefab) as GameObject;
2. Camera.main.GetComponent<CameraDefault>().target = myObject;

Something along the lines above should work just fine. It could be that "target" is not named target but something like "lookAtObject" or similar.

 

I've added this myself, but perhaps as a convenience feature this could be added for simple use in an update since parentRigidbody is private.

Code (CSharp):

1.         public Rigidbody ParentRigidbody
2.         {
3.             get
4.             {
5.                 if (parentRigidbody == null)
6.                 {
7.                     parentRigidbody = parent.GetComponent<Rigidbody>();
8.                 }
9.  
10.                 return parentRigidbody;
11.             }
12.         }

 

Is there a setting that let's me apply "brake torque" as a torque opposite to wheel rotation? It seems like brake torque is implemented as "reverse" torque. I would like you vehicle to stop if I'm hitting the brakes.

 

That is exactly what brake torque does. It applies torque opposite of the torque acting on the wheel as a result of it moving over a surface. If brake torque is set high enough it will immediately overpower the torque provided by the surface and lock the wheel, and the stopping distance will depend on friction curve, coefficients and weight acting on that wheel. I am not sure what you mean by "stopping if hitting the brakes" as it sure does. It is just a matter of applying enough brake torque to lock the wheel up if that is what you mean.

 

Hello,

Just bought NWH Vehicle Physics and I am trying to get it set up for a project. Are the wheels in WC3D affected by gravity? It seems that they aren't, which is causing strange behavior if the car gets lifted off the ground. It seems like the spring force and the mass of the car body is the only thing keeping the wheels on the ground. I could easily be missing something there, though, especially some reason why this would be a bad idea.

(Unity's standard wheel collider doesn't seem to have the wheels affected by gravity either, so I guess it may come down to suspension setup.)

Also, it seems like there is no way to add intrinsic friction to the axle itself, so that the wheel will eventually stop spinning when the car is upside down - although maybe that's a NVP problem more than a WC3D problem. Right now, if the car is in gear, the wheels will keep spinning at a constant speed and the RPMs will stick if the car is upside down. (I'll take a look and see if I can implement a fix for this by editing NVP to add a little bit of brake torque when the wheels are off the ground.)

Thanks in advance. I'm new to physics programming, and WC3D has already taken me way beyond anything I would likely have been able to figure out by myself any time soon.

 

Hello,
Yes - WC3D is affected by gravity. In fact, it was used in more than two low gravity games that I know of without any problems. What you are mixing up is the fact that there is no friction if there is no force on the surface. Here is a generic graph (the graph for tire friction does not look exactly like that but it should be enough to prove the point):



This graph is a bit misleading since it says Mass vs Friction - I am assuming the author just assumed standard gravity. More correct would be Weight vs Friction as weight is indeed directly affected by gravity and therefore if there is no gravity there is nothing pushing the vehicle to the ground and consequently no friction force. Just think of a rally car cornering over the crest.

If you are using NWH Vehicle Physics 1.9.2 there is actually a drag/friction field for the axles which does exactly that. Note that 1.9.x will not be available for download if you are not using Unity 2018.3 or higher.

Hopefully this clears things up.

 

Hello NWH. I was wondering if there is a quick guide to using custum friction curves? At the moment, I open the curve editor and adjust the curve as I see fit, and the curve appears to have changed, but when I run it in game, the curve seems to be replaced with default curve set by your script. Apologies if this has already been asked.

Tom.

 

Hello - yes there is. The curve you see and that you tried to edit is just a visual representation of the Pacejka Magic Formula parameters set inside WheelController.FrictionPreset.cs, starting at line 38.
Example preset would look like this:
public static FrictionPreset TarmacWet = new FrictionPreset("TarmacWet", new Vector4(13.2f, 2.35f, 0.82f, 1.0f));

Where the Vector4 represents Packejka Magic Formula coefficients [B,C,D,E].
These can be found around the net and in different books on the topic.
You can try tweaking the values one by one and you will quickly get the idea for the thing if you understand how the tire slip works.
And also do not forget to add the name to the enum below, in order as defined (so if you add you friction at line 52 just add the name of the preset as the last in the enum).