Wheel Controller 3D - Customizable Three Dimensional Alternative to WheelCollider

I just imported the package into an empty project and no errors. I have checked in Unity 2017.1.1f1, should not be much different in your version. Could you try importing it into an empty scene and loading the demo?

 

OK, I created a new project and imported the wheelcollider asset and it worked OK...so it has something to do with my project.
I created a new blank scene in my project and tried to import the asset...but it still comes up with the errors. Unfortunately I'm quite new to the dark depths of programming so I'm at a bit of a loss as to where to start looking on how to solve this problem. Is it trying to reference the Unity wheelcollider perhaps, even though its a blank scene?

From what I can tell is that all of the errors are coming from the fact that the WheelCollider in your script doesn't seem to have the definitions (all the red lines in the code are after a 'wc.' for example. I don't know if that helps. is there some way I can make sure the code is looking at your wheelcollider base script and not anything else?

I have 'using NWH.WheelController3D;' at the top of the script. But it's in a darker shade, I don't know if that's normal.

 

No, it does not have anything to do with wheelcollider.
I am still quite sure that this is a namespace or class name collision issue tho.
Another suggestion is to delete the WC3D folder completely and do a fresh reimport.
If your WheelControllerInspector.cs script does not start like this (note the "using NWH.WheelController3D") your files were not upgraded if you did an upgrade from older version:



So try to delete the WheelController folder and import again.

 

OK, I figured it out. I already had a script called WheelController.cs in my project...and it was looking at that for the definitions. Told you I was new to this! All I had to do was rename that script and it cleared all the errors.

Thanks for the quick support though!

 

Actually, this is a bug on my part. If you look at the image above you will note that there is no namespace part in WheelControllerInspector.cs which causes it to throw error. Well, one more thing for v3.1. I will dedicate this afternoon to testing and bug checking so that v3.1 is as bug free as possible. If the namespace was there, you would not get the error with other script of the same name. That is what namespaces are for.

 

Version 3.1 has been submitted to the store.

Version changes:
- Reworked longitudinal friction calculations.
- Added option for wheel to apply force to the hit rigidbody.
- Parent object is now found automatically.
- Fixed rim collider instantiating at the wrong position.
- Fixed slip coefficient not being used in some cases.
- Fixed vehicle side not being assigned automatically.
- Added wheel side option "Auto". When selected it will be replaced with auto-detected side.
- Added namespace to WheelControllerInspector script.

 

Using Version 3.0 from the asset store, my vehicle is constantly jumping around without any input,even though i have put all the vehicle colliders to Ignore Layer for wheel collider

What is the criteria/rule for setting position of Wheel controller script as i noticed they are not on the same position as that of wheel visuals objects even in your demo scenes?

 

Hello,
I would suggest you try to turn rim colliders off (option under "Wheel" in the editor) and try then. If everything is OK afterwards the problem is in this:

- Fixed rim collider instantiating at the wrong position.
​

This is a known bug in 3.0 and has been fixed in 3.1 which will appear in the store shortly. In the meantime I have sent you a link to 3.1 in a PM.

 

Hi, I'm loving the updates, this asset is getting better and better. I wanted to ask your opinion on something.

In Start() the Bounds is calculated through various calculations regarding wheelRadius and so I cut that and placed all of it all into a function called CalculateBounds() and so during runtime everytime I want to change the wheel radius I simply do

Code (CSharp):

1. wheel.radius = x; CalculateBounds();

and then the Bounds is recalculated whenever that is called.

My test have showed this is fine on the performance side (although it is questionable because I have a high performance workstation) but I haven't had any problems with it and I wanted to know if there is a better way to do this?

Here is a picture just in case I am bad at explaining it.

Edit: I wouldn't be using this every frame, it's more just for customization (wheel changes at runtime) or popped tires (radius gets shrunk by 15%)

 

It should be fine performance wise and if it is working fine I guess there should be no problems. All that code does is calculate from where rays will be cast. In pre 3.0 this was done every frame since rays were recursive and their position was not always known in advance, but now that they have fixed positions they get created only once. Since you need to change radius at runtime, this is probably the best way to do it. You would still be getting major performance increase from 2.2 even if you called it every frame, and off the top of my head I can not think of any bad side effects.

 

Hi, I am trying these wheels for 1/10 scale models and facing the following issues

1. I need to manually scale the wheel collider radius & width.
2. Whatever tweaking I make to wheel scripts, vehicle does not stop jumping (have set same layer for all colliders in vehicle - self collision excluded and also tried tweaking rigidbody weight, spring and damper values)

Similar setup with unity wheel colliders works fine.

Any suggestions?

 

Hello,
1. There is no automatic scaling implemented and for that reason wheel radius and width will need to be adjusted everyime something is scaled. I would implement something based on mesh bound extents but there is a large variety of wheels of which some are made of multiple objects, incorrect bounds, rotations, etc. So I left it at manual as it is the most rugged solution so far. If your models are correct you could set with and height through visual's mesh extents.
2. Solution to this is in most cases wrong settings. If you have 1/10 vehicle you would need 1/10 rigidbody mass (!), 1/10 spring strenght and also 1/10 damper force. So say 100 for rigidbody mass, 2000 for spring strength and 100 for damper bump and rebound. If you still will have problems with jumping after trying this you can send me a scene with your model and I will check it out. My mail is in the signature.

 

I have sent you the fixed scene and explanation to your email address.

For anyone else reading this the problem was that the object containing rigidbody which also happens to be the root object of the vehicle was scaled. This should not be done as per Unity guidelines, and I would suggest scaling the mesh instead of the root object - causes much less problems in general, be it with my script or any other.

 

Probably one thing I'm still struggling with here is that the simulation seems quite unstable - IE if you load up the demo scene and try to stop on any of the bumpy areas the truck will often oscillate its way out of them. Example:


From a stopped position (with handbrake) the truck can move itself forward by oscillating back and forth with increasing momentum.

I worry that in production this'll cause major issues when other dependant physics are also involved - A truck+trailer on a physics enabled bridge, for example.

As I understand it the physics sim just isn't robust enough to solve for such problems accurately, but can we maybe add some kind of damping when the vehicle is close to at rest and the center of gravity is close to center?

EDIT - Actually this can be largely reduced by increasing the fixed time step so maybe it isn't such a big deal. Though I still wonder if some damping might improve stability?

 

Hello.

The effect you are seeing is mostly due to the way normal is being calculated at the moment. As you might know raycast does not return anything else but a normal 90 degrees from the surface when passing it over sharp edges. One frame it is on the flat surface, next frame it is again on the flat surface - never knowing that the step even happened. I am for that reason calculating my own normal from the multiple ray hits (whose number is minimum for the purposes of performance). Since this is distance weighted average it tends to lag behind a bit - like any other averaged / smoothed function.
This has nothing to do with damping so changing spring and damper settings will not change this; it is an internal thing.
I will focus on that in the following update but since I do not consider it priority nor bug that update will wait for a few days (or a week or two) until I accumulate enough bugs to update (there have so far been none for 3.1 thankfully).
Also, the vehicles in the scene have 0 friction except for some drag from rigidbody so any inaccuracies get inflated over time. Since Unity drag is exponential it will severely limit top speed of any vehicle so I would suggest setting brake torque to e.g. 100 when motorTorque is 0. You could even keep it at 100 at all times as WC3D works with motor and brake torque at the same time up to some point (again, you might get some creep if you set both to very high values as a result of inaccuracies).

So that is my suggestion for now.

 

There will be a minor patch pushed to the store in a few hours. Version will stay 3.1.
Changes are:
- Fix for the text in editor that says "Side Friction Curve", "Side" will be removed so it is not misleading.
- Minor change to lateral friction calculation that will improve stability in some edge cases.

 

Hi NWHCoding,
I'm fairly new to Unity, and I don't know much of anything about coding, etc.. But I'm trying to get a bicycle to work.. I bought your Wheel Controller script (using 3.0, and downloaded 3.1, but I'm not sure if it automatically updates), and I can't seem to get it to work. The bike drops to the ground, and the wheels drop straight down, about half way through the ground also (separating from the bike), then it just freaks out, shooting all over the place. I followed the documentation, but I just can't get it to cooperate.. Even just colliding with the ground properly. Is there something really off about my settings? I have no idea. haha!

The model was created in maya, to real world scale, in cm.. which in Unity kind of messes with radius of my wheel (divides it by 100).

Here are some settings:
both wheels set to "Center", for what side the wheel is on.
Tire radius = 0.26
rigid body mass of bike = 12
wheel mass =10 (for both wheels)
rim offset = 0.2
Spring Force = 200
Spring travel = 0.26
Damper = 500
Rebound = 550
Wheel Scan- Forward Resolution = 10
Wheel Scan- Side Resolution = 5

I have the the Scan Ignore Layer set to Wheel Controller 3D, same as yours, and is applied to both wheel colliders

Forward, and Slide under Friction are default.

I want the bike to not have ANY spring action what so ever, it should be completely rigid. I'm not sure how to achieve this though... I've sent an email, but haven't gotten a response.

Thank you!

 

Hello and sorry to hear about your problems. I would suggest you check your mail and/or spam folder since I replied 8 minutes after you sent me the email.

One problem I am seeing with this is very low spring strength. 200N would support only 20kg before bottoming out. Also, rim offset is not needed on a bicycle since it has wheels in the center of steering. Check the mail for the rest of the answer.
Regards.

 

Got it! Yeah, it was in my spam folder. Thanks!

 

Hi.

I have tried many times to launch this fantastic asset, and I have not succeeded.

Always problems. The car jumps, the wheels disappear, code errors ...
Impossible to get it.

The car that I am trying to adapt is this:
https://assetstore.unity.com/packages/3d/vehicles/land/realistic-car-hd-01-74303

I do not know what to do. I do not know what I should report to receive help. I follow the manual step by step ... and nothing.

Help me, please.

 

Hello,

Possible causes:
1) Model rotation is wrong - z needs to be forward, same holds true for objects that hold WheelController component.
2) Object has rigidbody but no collider.
3) Ignore layer is not set.
4) Wheel Controller is attached to the wheel visual (it should not be).

Probably one of the those. If that is not the cause you could always send me your scene and I will look into it. But probably one of those.

 

Thanks for quick reply.
I will try again, just in case.

 

It is most certainly problem with setup. I doubt that you have discovered such a big bug since the asset has been out for some time and while there might be some smaller bugs - I can just say that most of the support that I gave the problem was in setup. Since the model is from the store model rotation should be ok but you never know. If that is the problem here is the guide to fix it: https://docs.unity3d.com/Manual/HOWTO-FixZAxisIsUp.html
But in most cases users forget to add ignore layer or just set up the hierarchy wrong. Your parent object should have a rigidbody and then (same as with default wheelcollider) WheelController objects should be on separate objects from the actual wheels.
One more thing - if you are using an infinitely thin model (not terrain) as surface you might want to disable raycast detection of back surfaces in physics settings (something along the lines "Queries Hit...").

 

Hi,

1) Would it possible to set the friction to full, so there is no friction possible?

An very important:
2) If the wheels start to lost it's traction/grip. Does this behavior is represented by a bool or a float?

If tires are starting to squeak silently in a curve, they do not lost it's traction.
Is it possible to have a response of this phase, from "start" - "until lost traction completely" as a normalized value?

If not, I would calculate it by my self by some easy properties. Car weight, speed, tire contact surface grip, curve radius (steering angle) and ground slip factor.

For me the new/old demo is unrealistic. On a dry tarmac without torque a car slips away at 120km/h when steering slightly. Dry tarmac behave like sandy tarmac in my opinion.

 

1) No. You could go very high but after some value you will start to get instability if you do not reduce your fixed time step.

2) Float.

I am not sure I understand the question with start and until traction completely. You can never lose traction completely if you look at the classic Pacejka curve (something along these lines, there is a preview in WC3D for a similar curve but I do not have Unity with me at the moment):



So there is not a definitive lost traction or has traction state. You can always get the current slip value.

In NWH Vehicle Physics - my vehicle package which is using WC3D and is awaiting approval at the moment - I am using user-adjustable variable for acceptable slip. This is probably the best solution as you can adjust when skidmarks and skid sounds start to appear, intensity of those and etc.

 

Did you manage to find the problem?

 

I do not understand exactly user-adjustable variable. Sounds like a set value.
Required is a "slip-return" value from your engine. eg.
~GetCurrentSlippingSingle(wheel).
~GetCurrentSlippingiAverage(wheelBL, wheelBR, [wheel], [wheel], ....)

 

Oh, you misunderstood me there.
Slip you can get for each wheel using:
forwardFriction.slip
sideFriction.slip
Value will be positive or negative depending on the direction of the slip.
I was just mentioning that you can use some arbitrary value (e.g. 0.3 for forward and 0.1 for side) to detect if wheel is slipping, so:

public bool isSlipping
{
get { return Mathf.Abs(forwardFriction.slip) > 0.3f ? true : false; }
}

Just writing that off the top of my head but I am pretty sure it will work just fine.

WheelController3D is a replacement for wheelcollider and as such each wheel only knows about itself so you can not get slip average for the all wheels from one wheel (no point in doing that). This should be done by the vehicle controller you are using - if it supports it.
I was mentioning that the above method is how I had done it in my other asset that uses WC3D:
https://forum.unity.com/threads/wip-nwh-vehicle-physics.506909/

 

Hi, I almost never post on the Unity forums, but I will feel bad if I don't say something.
First off, WheelController3D is awesome. I've been performing many stress tests on PC and mobile and it performs really well. I'm planning to use it instead of the standard unity wheelCollider for my upcoming game.

With that being said, in Unity 2017.3 there is Garbage collected constantly when Wheel Scan > Apply force to Hit checkbox is selected.
See image attached.

I removed the garbage by changing a few lines in the WheelController.cs UpdateForces method...

From this:

Code (CSharp):

1.  
2. if (wheelHit.raycastHit.transform)
3. {
4.     Rigidbody rb;
5.     if (rb = wheelHit.raycastHit.transform.GetComponent<Rigidbody>())
6.     {
7.         rb.AddForceAtPosition(-totalForce, forcePoint);
8.     }
9. }
10.  

To this:

Code (CSharp):

1.  
2. if (wheelHit.raycastHit.rigidbody)
3. {
4.     wheelHit.raycastHit.rigidbody.AddForceAtPosition(-totalForce, forcePoint);
5. }                
6.  

Tested in an empty scene with 20 of the vehicle prefabs, with CarController script disabled. The garbage was removed.

One of the other issues were with GenerateRimColliderMesh creating the mesh too large or small due to vehicle or wheel scale - but you may have already solved that in your new vehicle physics asset.

I am truly looking forward to the new Vehicle Physics asset. Keep up the great work.

 

No... sorry.

I have achieved very manually that the wheels do not disappear or hit jumps, but the car is "untranslatable" ignoring the reason.

In the tab "scene" I see that when the car starts, the "green" areas are always ahead. Very unmatched. I do not know how to explain it.

I'll keep trying. I think that if others get it, it's not a problem with the plugin, it's mine.

Thank you.

 

How do I return the sprungMass? I'm in the process of replacing Unity standard wheelColliders in my project and sprungMass isn't found in wheelController3D. That's the only thing I am missing.

I can divide the mass based on the total wheels at the start, but it wouldn't be dynamic with the vehicle weight while driving.

 

Thank you for the heads up. I must admit that the force option was added just before publishing and therefore not profiled. Will implement the changes in the next version.

 

I did not receive any emails so that is why I am asking. "green" areas are not exact representation of physics postion since they are not updated in FixedUpdate() but rather when Gizmos are drawn, so if they are ahead or behind does not mean that the physics is.

If you want you can always send me your project folder and I will have a look at it.

 

There is no exact replacement for sprungMass but you could use "wheel.tireLoad". Difference is that the sprung mass will always be larger than zero and tireLoad will be zero while in air. Hopefully it will suffice.

 

Version 3.2 is on it's way and will be approved in a few days.

Changes:
- Compatibility update for upcoming NWH Vehicle Physics.
- Removed garbage collection when "Apply force to hit objects" was set to true.
- Micro-optimizations (reduced function calls, etc.)

 

Wheel Controller 3D v3.3 has been pushed to the store, allow a day or two for it to be available for download as it needs to be approved by the Asset Store team first.

Changelog:

• Changed the way forward friction coefficient affects the forces. Increasing the coefficient will no longer increase the torque but rather the torque limit before slipping which is correct.
• Big improvements to the general feel of Wheel Controller.
• Fixed spring length difference between single and multiple ray modes.
• Fixed wheel stops spinning if not powered as soon as it loses contact with surface.
• Fixed bottoming out calculation.
• Gizmos are only drawn when object selected to reduce clutter.
• Fixed problem with ground detection not happening at the lateral center of the wheel when side resolution was 1, but rather to the side.
• Scan ignore layer(s) are now selected through a dropdown with tickable ignore layers.

 

Overkill for a skateboard perhaps? I am finding very strange behavior using WheelColliders. This is most apparent when landing on the ground after a ramp or jump.

 

Overkill for sure. You are getting the weird behavior because of how wheel collider handles bottoming out.
One thing that will be a problem with WC3D is the fact that it has to have suspension length >0 to function properly and on a skateboard that might not be convenient. Other than that source code is fully open so modification is possible if needed.

 

I figured it might be overkill. Well, great work on this package anyway! I have also found that very small suspension distances do work, but takes some finessing. I've helped matters by including another box collider underneath my skateboard to help "absorb" impacts from landings better. It really takes a load off of the WheelColliders when landing from high up at higher velocities. It also had the added benefit of allowing me vertical OnCollisionEnter callbacks. I couldn't get those from the WheelCollider as far I know. I was using WheelHit, but it was running every single frame (raycast).

 

Glad you managed to get it working.
Rim Colliders are there just for that reason although on the last update there were some large improvements to the bottoming out force calculation. But since a skateboard does not actually have steerable wheels (at least not by much) using box collliders is maybe even more practical.

 

Any ideas how to fix this issue? Wheel Controller 3D v3.3

 

I use a heavily modified version of WheelController in my game

 

The issue manifest itself in this code's line
WheelController.cs/SuspensionUpdate():

Code (CSharp):

1.  
2. parentRigidbody.AddForceAtPosition(spring.bottomOutForce * transformUp, transformPosition, ForceMode.Impulse);
3.  

 

Hello,
sorry for the delayed response but I would swear I responded to this but now that I look at the posts there is no response, interesting.

The problem here is with ground detection, bit it is more of a limitation of the way things are implemented then a bug. Wheel detects the step as ground and tries to lift itself up but since the step is so high it ends bottoming out the suspension which is the line of code you pasted. To avoid this my suggestion is to use rim collider, an option for which the checkbox can be found at the top of the WC3D inspector. This will add a collider that follows the wheel and disallow ground detection when it should not happen.

 

Thank you for the answer. Sent details in the PM.
Regards

 

Just bought WC3D a few hours ago, everything works as expected except I can't change the size of the tire at runtime, is there anything else I should do besides changing the "Tire Radius" value in the inspector\from code? In the scene view the gizmo is clearly changing but the vehicle remains exactly the same.

 

Runtime readjusting of the tire size at runtime was removed in v3.0 and the needed calculations were moved to Start() to avoid CPU intensive operations each frame. Now that you mention a good idea would be to recalculate the tire radius on radius change.

What I would suggest doing is moving lines 205 ("// Scan start point") to 240 ("}") to a public void function of any name and then calling that function after the wheel radius change, or calling it each frame in fixed update (but not recommended). I have just tested it and it works as intented. Rim collider will not get resized tho and if that is the problem I will send you the complete code, just PM me.

 

@NWHCoding Thanks for the fast reply, it works great!
I have another question though, I'm working on an integration between your asset and mine, if possible I don't want to ask anyone to modify WC3D - any chance you could add a public function what I can call to recalculate the radius in the future? (it's a fake tire deformation solution so radius change is a must to make it look convincing - simply copying the lines to a public function as you said would be perfect, no need to change the rim collider at all for my case)

 

I have just submitted the updated version with this inside - sorry for taking my time but was out of office for the most of the week.

 

Hi a proper 3d wheel collider is much needed but in the demo for this you can not hold the vehicle on a slope - always it just slides slowly down, even sideways - which is a bit of a non starter for any wheel controller I would think. Is there a fix for this?