Wheel Controller 3D - Customizable Three Dimensional Alternative to WheelCollider

I got an idea when I looked at your images and replaced the capsule "rim" collider with a thing box collider that is positioned something like the 2nd image in the "Possible Solution" but thinner. Apart from that I spent the afternoon reworking the suspension so it should be much better now. I will PM you the modified script and will post the update 2.0 to the store after some more testing.

 

In our project we got weird unity bug. In some places on maps we using mesh terrain with mesh collider instead of default terrain, so in that places I got FPS down from 60 to 7 fps using wheel controllers. Disabling rim collider returned back my fps to 60. I start searching for source of problem and found it. Our designer don't want to waste time for convex colliders for mesh collider on terrain and just switch it to concave, and that is a problem. I know that unity don't work correctly with concave colliders, but wheel controller was far away from that terrain (was under, about 200-400 meters) and even don't touch it.

Just wanna tell my story, coz this can happnin with someone else..
Sry for my english.
Peace

 

Thank you for the input.
Unfortunately this is something that I cannot do much about. It is interesting because you mentioned that rim collider dropped your FPS and rim collider is nothing else than a CapsuleCollider (or BoxCollider with the incoming update) so enabling or disabling it should not have any performance impact. What is happening is probably Unity querying the terrain for the collision with the rim colliders and since they are concave that can be very slow. Why Unity might be checking so far from the vehicle I have no idea and probably only they know it. If your part of the concave mesh terrain is big it could be that it is checking all the parts of if one part is close, no matter the distance of those parts.

As mentioned, cannot do much about it myself since it is Unity internals and you are the first to have such problem.
Regards

 

Yes, and as I said that is unity bug/problem, not Wheel Controller. Something like: when CapsuleCollider pass to the concave mesh collider bounding box- it start lagging (not sure). 8 CapsuleCollider's drop fps from 95 to 1 fps

https://dl.dropboxusercontent.com/s/4aslog8bbdrlrfp/Unity_2017-02-24_11-00-58.jpg
Disabled: https://dl.dropboxusercontent.com/s/xqcmmkksk8sgosv/PicasaPhotoViewer_2017-07-14_21-54-52.png
Enabled: https://dl.dropboxusercontent.com/s/jk53vc0nnre919g/PicasaPhotoViewer_2017-07-14_21-55-25.png

 

Thanks for the info, certainly an interesting behavior. I can PM you the script for the v2.0 that will be out during next week (still testing) if you want to try it with the reworked suspension and most importantly it now uses box collider set up a bit differently than the old capsule collider. Box collider is still optional tho and as before the asset will work if disabled.

 

I had to update my version at least to latest WC version. I made a lots of changes to WC code (custom layermask, disabling rim, etc.) as I wrote above, and this will take some time. I should do that coz there was a lots of WC improvements and optimisations, old WC code eat up too much resources if you have ~20 vehicles with 8-12 wheels, so I had to decrease raycast count per wheel.
I think I can manipulate raycast count (mean wheel settings) according to distance to camera (just got this idea).

 

That was exactly the reason why I implemented the adjustable resolution in the first place. If you use the resolution of 1,1,1 you will get the behavior of the default collider with single ray which is enough for distant vehicles, and then you can use something high on the player vehicle. Unfortunately there is not a method such as a CylinderCast that could be used so that cast has to be approximated with rays instead.

 

Thanks again for your fast reply and for be working in the solution! I´ll wait until 2.0 version. 5 stars for you in the asset review!

 

Hi! Your asset looks very promising (did not try it though). Right now we making game with monster trucks and WheelCollider looks awful sometimes, so we looking for better solution. I have a question. Will your solution handle situations when truck must rides on rear axle only and it's front looks upwards? like here https://giphy.com/gifs/monsterjam-3o7bu66vX6tUEVvFpS

 

Hello. I am sure that WC3D will behave better than the WheelCollider in such situations but it is a bit of an extreme case and WC3D has not been designed for it. Biggest problem would probably be similar to what you have now, and that is when the vehicle is at some weird angle (standing up on it's rear for example) ground detection is only happening towards the bottom of the wheel, not in all directions - this will cause some problems with jumpiness and such. If you are willing to try I can offer you refund if you do not make it work or are not satisfied with behaviour.
Sorry for the blob, I am on my mobile at the moment.

 

Thanks for your ansver! I spent several hours trying to tune settings for my case. Unfortunatly it seems that WC3D works much better in most cases but in super extreme angle (almost 90 deg.) truck behaves not better then with wheelCollider (sometimes even worse).. No miracle for me today. Will make some more tries tomorrow though.

BTW can you give me advice how can I make tires extremely grippy (forward and more important side grip, since side slipped monster truck looks awful) without having artefacts like little sliding to side when truck just standing still.

 

Yeah, unfortunately making a wheel like the one you require would only be possible with truss physics or something similar but that is very very expensive. There is no access to the source or the physics engine underneath so API is limiting the possibilities.
As for making tires extremely grippy, force factor is probably the setting you want to play with - set it to e.g. 1.5 or if you want it really grippy 2. Last time I tried this it was quite grippy. In fact I think 3 should work too. That is 3 times the grip of a default tire (the tire info that I used for the asset is from 70s so 1.3 would be about right for normal modern tire).

 

The time has come for me to want to buy this asset now and I was wondering if I could receive some insight on the asset. I'd like to use your wheel mainly for the 3D aspect of it as I will have some rock crawling and such going on, but to also combat the ugly wheel sinking problem that plagues single point raycast wheels but I'd also like to make sure your wheel can handle what I do with the default WheelCollider.

1. How does your wheel handle realtime friction curve changes? The PhysX WheelCollider gets very jump and unstable when simple changes are made to it because I allow users to change it with an in-game menu to adjust it to their liking.
2. How does your wheel handle realtime suspension length/distance changes? Users can also change this with an in-game menu.
   
3. How does your wheel handle very low suspensions and bumps? The PhysX WheelCollider will violently "pop" back into the suspension range once it bottoms out.
4. How does your wheel handle being on it's sides? The PhysX WheelCollider cannot do side detection at all and will start sliding or violently "pop" until the wheel isn't on it's side anymore.
5. How does your wheel handle high friction curves without changing the center of gravity? I find the only way to make higher grip friction curves function adequately is to make the center of gravity lower in addition to lower suspension distance and higher spring rates. If the suspension is left like a regular car but you provide (compared to a sports car) higher grip curves (like a racing slick vs regular tire) then the WheelCollider becomes unstable.
6. Is their visual wheel smoothing? If not is their anything limiting this from happening? The standard WheelCollider doesn't play well with smoothed visual wheels.
7. Does your wheel include camber, caster, toe, etc?
8. How does your wheel perform compared to the stock WheelCollider?

If you'd like to see some problems I am having with the WheelCollider you can see a video here.

Things to note for the video

• The suspension is never overdamped (bottomed out)
• The center of gravity is fairly low
• Anti-Roll bars are being used
• The friction curve is the default curve with slightly higher grip
• Half way through the video I adjusted the gravity on the fly to be higher and the car acts almost the same.

 

Hello and thank you for the interest. So here it goes:

1. No problem. Actually, you can do that in the web player demo by clicking different buttons on the top left. What that does is simply change the curve. I took that part into account when developing and there is API for changing the curves. You can assign one manually or generate it with the inbuilt generator and 4 parameters (Pacejka BCDE).
2. Also no problem. Try to not set it to 0 in between and you are good to go.
3. The car in the demo has spring travel of 0.2. 0.15 or so is the lowest I would recommend. That should be adequate for any sports car. Bottoming out has been fixed in the last version so there should be no problems with bottoming out.
4. Side detection is about the same as the wheelcollider but the violent popping has been handled. Also it uses so called "rim colliders" that handle collisions from the side. Essentially box colliders that move with the wheel and are placed in the middle, like slate.
5. There is both slip and force modifiers both for forward and side friction. If you adjust the force modifier (default is 1, stable up to 3 or more but depends on the vehicle) you will get what you need for your sports car. I find that a 1.4x force modifier with a standard Tarmac curve is good for road cars. Note that the provided curves are from a standard tire from 70s as that is where the data came from, so setting it to about 1.4 seems like a correct value for a modern racing tire. Realistic centers of gravity work well. Both of the cars in the demo have the center of gravity 10-20cm above the seating height.
6. When developing it i was careful to not tie in visuals into calculations meaning the wheel can function without any visuals - just don't assign them in the inspector and then move the visuals yourself however you want. API provides world position and rotation so you can use those and smooth the values however you want. If you use WC3D to move them tho, there is no smoothing inside the package. Everything you see is from that frame.
7. Unlike the wheelcollider, you can rotate WC3D however you want. Rim offset is in the package along with camber, but things that are vehicle specific (this is a wheel asset after all) can be done by simply rotating WC3D's transform. E.g. rotate it around y axis to get toe, or around z axis to get caster. I have tested this and it works great, not to mention that toe in and caster actually affect the handling accurately to all calculations being in the wheel space. That means if you use toe-in it will actually turn in better but be more unstable, etc.
8. Depends. Scan resolution is fully adjustable. Set all the resolution variables to 1 and you get performance that is near the wheelcollider's (most of the cost in this case is from calculating all the geometry parameters, Vectors, etc). This is the excerpt from manual which was written way back for version 1.0, it mentions 100 rays which is enough for all 4 wheels:

... script will use up 0.35ms of CPU time on an Intel Pentium Dual Core machine, and of those 0.35ms 0.25ms is spent on raycasts. For default values which are more than adequate in most cases script will use 0.19ms per wheel, of which 0.12ms for raycast. So the average time for one raycast in this case is about 0.003ms.
​

There you go, if you have any more questions I am here all day

​

 

Glad to hear I ended up buying the asset and I am integrating it as we speak. I did have a problem from some early testing though.

• I was testing changing the spring length in realtime and the car gets very jittery if I go past 0.6 but it gets really bad around 0.7 and higher. Is there a reason for that?
• The car seems to slide (when standing still) after a certain time of driving, only way to stop it is holding the handbrake. Is there a wheel sleep velocity?

Edit: Some more info, it is jittery in the demo scene also. If you goto the sports car and set the spring length to 0.7 it gets jittery.

Spoiler: GIF

http://imgur.com/6rEn3qy

 

Have you troed to adjust the damper. It seems to me that when you elongate the spring so much suddenly your spring travel becomes so much larger (and with that increase in velocity of travel) that you might need to reduce the damper. The other possibility is center of gravity getting high.
There is no sleep implemented at the moment. Mostly so that cars can be interacted with by other cars. But if you want you can freeze rigidbody when velocity is under some value if that is what is needed.
And after all, if you do not find that it fits your needs I can offer you a refund. I am saying that because some of these limitations are engine limitations and as much I would like in some cases it cannot be solved. After all you noticed that even the default wheelcollider that uses substepping that is not available to me has problems in marginal cases.

 

I guess you can scratch that, I found the sliding was only happening when the car is jittery, it behaves perfectly fine when the suspension is properly adjusted. I found out the damper on the default WheelCollider doesn't affect the wheel as much as it should so since my script was setup for the default wheel it wasn't modifying the damper enough to match the length. Everything else is behaving like it should.

 

Glad it does. Don't foret to try and change the default damper and spring curves, they can change things drastically.

 

Well I'm not sure what I did wrong but the suspension is acting very rigid no matter how low the spring rate is and the wheels are micro-stuttering at a stand still. It seems hit or miss whether it wants to behave or not?

Maybe this GIF will help you? Maybe I am doing something wrong.
https://gyazo.com/88ed54373e254c7467805821c3a47d6c

These are the spring/damper settings, nothing wild.

 

Check if your damper goes to about 4, 40 on x, y (x represents velocity), not 0,1 like the defaultncurves are. Damper forces are multiplied by it so the steepness of the curve is very important. Apart from that could it be that you changed center of mass? Seems ok tho at the first glance. After all you can copy from demo scene.

 

Well I instantiate my cars at runtime so I can't exactly copy the demo scene, I did copy the exact wheel component from the SUV wheel to my car and setup the references right and it seems only my car is having the problem. If I drag the SUV to the scene that has my car the SUV is completely stable and fine no matter what I do to it but the car is unstable, bouncy, and grips like it's on rails. I feel like I may be doing something in my code that I might not be realizing.

Edit: Sorry the curve starts at 0,0 and ends at 10,40

 

Hmm, the only thing that comes to mind is that the layer is not set to ignore layer (20 by default) so wheels might be colliding with the vehicle itself. Tick the debug in the WC3D inspector and turn on gizmos for more visual info.

 

Alright thanks for mentioning the COM, it seems like the wheels don't like a COM that is above the wheels. They seem to trip out as soon as it goes over them which kind of confuses me because the SUV does just fine with the COM over the wheels.

 

It is not about wheels but rather where the WC3D transform itself is, i. e. where the spring is attached.

 

I'll be completely honest in saying I don't understand a word you said lol.

 

I meant to say that spring force is applied where the GameObject containing WheelController3D script is and that this point is important when adjusting the COG. I have tested the default wheel collider and stability with higher COGs is about the same as WC3D. It is all down to the physics update rate, 50Hz by default. Most PC simulation and race games work at 100Hz and it really does wonders for Physics. Unfortunately, it does not do wonders for CPU usage.

 

Hey NWHCoding,
Got the same problem as ModularBuilds has, jittering does appear even on your included SUV prefab. To repeat this problem just set the center of mass higher and move it to the back a little. I don't know why it influences calculations, but moving center of mass to center of car solved the problem.
Also those who don't want to change the COM - just decrease fixed time step from 0.02 to 0.015 - that fixes the problem too.

 

Hello,
Actually, COM does not influence any calculations (not directly) and they are still *correct* no matter the COM. Problem with high COM is the fact that, due to the discrete nature of the system with long intervals between calculations, as soon as COM goes over the center of the object rigidbody becomes inherently unstable, i.e. wants to tip over. Think of it as balancing a stick on your finger. Now imagine that you can only move your finger only so often. Even if you managed to keep it upright it certainly would not be perfectly still as you would have to overshoot to compensate for the time in which you could not react. That is exactly what is happening here when COM is high. I tried to use COM script with the inbuilt wheel collider and same problem is present - even with the sub-stepping they are using and which is not available to users. And this is the reason I cannot do much about it, except as you mentioned reducing fixed times step which is not the best solution.
Hope this helps clear things up

 

That'd be cool if you mentioned that in the FAQ. I've spent a couple of hours trying to nail that jittering.

 

Will do!

 

@NWHCoding I have just bought this and started playing with the demo scene. Later I need to implement into my current vehicles. I am somewhat confused by one thing... Shouldn't changing the Max Motor Torque in turn change the top speed of the vehicle? It does not seem to do this in the demo scene or have I just not looked into this deep enough yet?

On should have said.. I know that torque is not the determining factor in speed necessarily. I guess I was hoping for a quick and easy way to test out a fast car setup. The car in the demo scene is not very fast at all, so no very useful for a quick and easy test.

 

Both cars in the demo scene have linear drag set pretty high because the cars in the scene only have a very simple controller which would allow them to accelerate to infinity were drag set to 0. I suggest you set that to 0.1 or maybe lower and cars will have higher high speed. That should do it. I will expand the test scene along with reduced drag in 2.1, thank you for the heads up.

 

Ah thanks for the info. This will make it just a simple quick test before I dive into integrating into my other cars, which I will have a go at next week. They are currently using RCC so hopefully not too much involved in getting it up and running.

 

@NWHCoding Unfortunately it does not seem like it will be very easy to integrate into RCC which is a pity. I don't suppose there is any guidelines that might help with this?

 

Last time I was helping user about something related to RCC it seemed full of little fixes for the default wheelcollider. Any specific problems? I would suggest starting with the most basic setup - one car on flat surface, maybe even the SUV from the demo - and building from there.

 

Yeah, should have document to port this to RCC asset.

 

I will focus 2.1 on making WC3D's API as similar as possible to that of default WheelCollider. It is 95% there, but there might be some discrepancy in returned positions where mine are global and WheelCollider also sometimes return local, and similar to that. As for porting to RCC - I cannot give support for asset from another author - and besides that my own vehicle asset is in full time development at the moment which will use WC3D.

 

I agree with this, I had no problem porting over the 3D WheelCollider to my physics which had a bunch of fixes for the default WheelCollider. It just takes some time to replace and change whatever values or functions that are different. I'd say it's a piece of cake for anyone with basic programming experience.

 

Just a quick note / suggestion. It just came to me that I forgot to mention anywhere that WC3D runs at any fixed update rate (50/100/200Hz, etc.) and so if you can afford it I can recommend running it at 100Hz for PC games that are simulation style. This way you can tighten the curves even more and have more extreme setups. The option is under Edit > Project Settings > Time > Fixed Timestep for those new to Unity.

 

Version 2.1 on the way.
- Removed slip smoothing when running at 100Hz or higher for tighter response.
- When vehicle cannot move and torque is applied to the wheels, if the torque is lower than what tires can handle tires are now completely still - not slowly rotating like in v2.0
- Small fixes and improvements.

Update will be out as soon as it gets verified by the Asset Store team.

 

I just picked up WC3D today, and got this error when importing version 2.0 into my project:

Assets/WheelController/Demo/Scripts/CarController.cs(15,14): error CS0101: The namespace `global::' already contains a definition for `CarController'​

After checking the script, it appears that you don't use namespaces, so your CarController conflicts with the existing CarController in the Unity Standard Assets collection. I know you've got update 2.1 in the pipeline, and maybe it deals with this already, but if it doesn't, you should definitely address this. I tried adding a namespace to the script, but that only resulted in 4 more errors popping up, so the rest of the scripts in your package need to be modified accordingly once you start using namespaces. Since you're marketing this as a direct replacement for Unity's wheel colliders, it seems like it should be able to coexist with Unity's Standard Assets, or other possible vehicle assets, without generating errors like this. Namespaces seem like good coding practice in general, and definitely seem to be needed here.

 

Hi I want to try this asset. I want to know whether this support one Vehicle dragging another vehicle like plane using hinge joint.
thanks.

 

Yes, true dat. It is an oversight on my side and will be fixed. Not much work to be done but no reason for customers to do it All the newer packages that I am using are using namespaces, and I am pretty sure some of the scripts in WC3D use them, but not all. I already pushed 2.1 bit will push again with thi fix. Thank you for heads up.

 

Yes, you can connect two vehicles like that no problem. Just note that the wheel is what this package is about, not the vehicles. You will have to connect vehicles manually tho as no such script exists in the package, and the included CarController is just a simple demo script just to make vehicles move.

 

For 2.1 demo, if possible.

1) I would like to have a larger scene track to test your demo at higher speed until 300km/h. This requires a scene width from about +/-6000m.

2) A camera setup that behave like a follow cam behind the car. This is very important to determine reaction on higher speeds. Currently the cam floats away on a curve

And more
3) Is there any event or variable info, if the contact of the wheels get completely lost from the ground? I'd like to raise damp factor (or similar) absorb roll and pitch energy.

4) Would it be generally possible to change any basic parameter (friction, stiffness, etc) slightly without destroying the current working physic? rg. Currently wheels rotating if the car lay on any side or roof.

5) I want to have a different reaction while holding brake from +speed until 0km/h. Your controller starts to drive backward directly from 0 to minus speed without a short pause. Generally, would it possible to change these behaviors by c# scripts, or does the complete reaction to the car is calculated inside a dll?

thank you.

 

2.1 is out but 2.2 will follow soon. To answer the questions:

1) New demo scene is in order for sure.

2) This is because there is some smoothing to the camera so it is not all jerky. Will sort it out.

3) Yes there is, there is a bool in the API that informs you if wheels are on the ground. Also, suspension is 100% adjustable so you can adjust spring and damper strength as long as it is in the realm of reasonable.

4) Yes it would. That is the idea behind the package - being able to customise it. Adjustable friction curves for both lateral and longitudinal friction, spring and damper. As for the wheels rotating when on roof - should they not? - they don't have much friction when not in contact with ground and so they start to free-spin. Think of a rally car jumping.

5) Current vehicle controller is just for demo. This is a wheel asset but it would not make much sense if cars could not move. It is only about 100 lines long and just applies motor and brake torque to the wheels, along with steering. It does not simulate gear shifts or anything fancy like that, just multiplies input with torque and applies brakes if that input is in the opposite direction from vehicle travel.

There are no DLLs. Everything is plain C# and you can modify it as much as you need / want.

Hope this answered your questions

 

I think they shold not. If the car crash and lay on side or roof, the wheels should stop spinning after the next few seconds. Good to know its possible to have access to the c#. Other guys asset using dlls, so eat or die.

Your demo controller works so far nice, why rebuild all up from scratch?!
I will buy your asset, it's definetely my choice.

 

Actually, if the engine is running and the wheels are in the air that just means that there is no resistance. Just check out rally drivers jumping where they hit rev limiter most of the time. In the case of the demo vehicle controller there is nothing to stop wheel from spinning while in air except for friction, so it just keeps speening under its own inertia until it stops.

 

I mean and wrote, after a crash and vehicleBody.velocity.magnitude = 0.0. Then the wheels in your demo spin for ever.

Is your PM off? I ask you something about payed scripting help but you didn't reply. Would be nice if you can reply, as well if you don' want or not have time for.

 

Check your email, I wasn't next to my PC this morning.