- Home /
RTS Units; Wheel Colliders
Hey fellas,
So I'm working on more or less an RTS game. I have a nice vehicle movement engine that drives vehicles around using WheelColliders. (An average tank has 8 WheelColliders; four on each side.)
Trouble is, it would seem WheelColliders are fairly CPU intensive. With 20 tanks on the map, my framerate chugs down to 20 or so. If I remove the WheelColliders, the framerate shoots back up to 50+, even with all my complicated trajectory math and such for the turrets.
Is there a good alternative to WheelColliders, or a way to drastically reduce the resources they pull from the Physics engine?
I really don't want to resort to just adding forces to vehicles to 'shove' them along the terrain. that seems so barbaric.
Thanks guys,
Wes
Answer by Fattie · Oct 02, 2012 at 07:33 AM
Sarge,
something like wheel collider is - let's say - a "detail level" piece of equipment.
if you have a Thing that is fairly large on the screen and there's a few of them (2, 3, 4 maybe) - you'd use such a "detail level" piece of equipment.
another example might be, oh, using a rig that has complex bones and IK you know, imagine say some sort of complex fighting monster.
So stuff like wheel colliders, IK, bones ... it's for close up main things
You would struggle to use that sort of technology, on "melee" things - where there are 10s of the item in question contained in the scene.
So this is a perfect example of that.
In your game do you ONLY SEE the tanks from afar? Or do you zoom on one of them from time to time?
What you have to do is essentially have "LOD rigs" to coin a phrase.
Your tank will work in a completely different way when seen from a distance / when many on screen, than, when it is the focus of attention.
It's difficult to talk about these things in total abstraction, post some screen shots. But when seen at a distance by the dozen, for a "bouncing along" effect you may do something like -- just one guess off top of head -- just add a little random pitch to the tanks. (or you could have one of a few hundred pre-computed random animations ... whatever, there are dozens of solutions).
if necessary for the treads wheels to jiggle up and down ? (even when seen at a distance) .. again perhaps just randomly jiggle them, or whatever.
BUT when you come in for a closeup, you utterly change to an entirely different paradigm. whether IK, bones, wheel colliders or whatever the case may be.
maybe that general "LOD rigging" approach will help you
to be sure to be sure ... when they are OFFSCREEN you are not bothering the wheel colliders, right?
(Again It's difficult to talk about these things in total abstraction, post some screen shots)
Just FYI I actually had no clue that wheel colliders were expensive - it seems weird as it's not much more than a raycast. who knew? For that I thank you for raising the topic! (you're really sure it's not something else you're doing?)
Just FYI ... "even with all my complicated trajectory math" .. that's nothing, no issue there
Cheers
Fattie, thank you for the awesome response, as always!
Your discussion of the "large, detailed" vs. "small, simple" resonates with my project. You drive a big battle-train thing, fighting against hordes of relatively smaller vehicles. Your philosophy has lead me to the conclusion that the player's battle-train, which is the core element of the gameplay and has lots of parts to zoom in on and manage, should be driven with wheel colliders and other involved physics... but all the little tanks and jeeps scurrying around (with estimated lifespans of 5-20 seconds) don't need such detail.
As cool as it would be to have all the vehicles in the whole game have realistic physics simulation, you are right... It's really not necessary.
I am very familiar with changing rendering detail at different distances from the camera, but it had never crossed my $$anonymous$$d to dynamically change the level of physics simulation detail relative to distance! That is a very interesting concept. I will look into this, though for now I think I am going to strive to just keep the locomotion of most units very simple.
(The only reason my trajectory math is--and has been--an issue is because I have a series of formulas that calculate not only the angle at which a turret must shoot, but also how far ahead of the target it must shoot in order to hit a moving target. There is mathematically no 'closed form' for doing this, so I can't 'solve' it in one function, so I ins$$anonymous$$d have to run a series of trajectory/target-leading functions many times each frame to sort of 'zero in' on the 'correct' values... With 300 units on the screen each perfor$$anonymous$$g a function with 3 gigantic equations about 10 times each per frame, that script does make a pretty big footprint on the profiler if I don't keep an eye on it!)
"dynamically change the level of physics simulation detail relative to distance!" ... exactly "LOD rigging," to coin a phrase. It sounds like you've got it by the nuts now, good luck !!!
Answer by Muuskii · Oct 02, 2012 at 05:01 AM
According to WheelCollider it uses a ray facing straight down which is probably the biggest drain you have in your game.
It sounds like a design choice going on right here; Why does your game need realistic physics in a strategy game? I can understand physics in a racing game. But when I'm playing an RTS I want the movements to be as easy to predict as possible and physics is not conducive to human prediction.
I wouldn't be surprised if a game like Starcraft was really just a bunch of CharacterControllers who's Y coordinate is set to Terrain.Height(x,z) In fact, I might have read something to that effect. . .
Thank you for the reply! You have coaxed me into rethinking the level of detail I want in my game... It's a fundamental game design problem, the push-pull of detail vs. density of elements.
Your response also led me to the "Terrain.SampleHeight" call, which I didn't know existed. I will cook up some code using that for driving my units around. Thanks!
Your answer
![](https://koobas.hobune.stream/wayback/20220613081741im_/https://answers.unity.com/themes/thub/images/avi.jpg)