New Wheel Modules

[DuoDex]

Full story here.

Discuss.

[basic.syntax]

Nice words that offer hope for a great future - but too soon to tell if the end product will be better than a copy of current wheel behaviors (Squad's primary goal in a port: just get it all working, first.)

[mythbusters844]

I just screwed around in the physics demo (instructions here) for a full twenty minutes and was quite entertained and impressed. If the new wheels behave like this then a lot of long-standing issues relating to wheels will probably be solved.

[Feradose]

Oh man am I drooling, does this mean I can use the large wheels rotated 90° for low profile giant craft? Will wheels just clip through the ground like now or would it work?

[Wjolcz]

So the wheels will actually work like the old Bobcat wheels and not skis?

[passinglurker]

My big question is how hard/easy is it gonna be for modders to make their own? Presently the art of wheel making is treated like mysterious black magic.

[Captain Sierra]

I have not tried the tech demo, so I gotta ask. Does this fix the lack of response time on steering?

[Murph]

Oh man am I drooling, does this mean I can use the large wheels rotated 90° for low profile giant craft? Will wheels just clip through the ground like now or would it work?

I wouldn't count on that changing. There's an extremely good reason for that behaviour in terms of physics performance. Wheel collision has to be evaluated every physics frame (many times per second), for each active wheel. That particular simplification is a very necessary part of typical wheel physics modelling, by casting a ray in the direction of the wheel's "down" (which is not the same thing as gravity "down") to find the terrain or object that it should be colliding with. It saves a significant amount of computation over actually trying to accurately model the collision of a cylinder with uneven terrain.

I'm sure this library is probably a good one, it certainly sounds good, but it is still constrained by the need to fit the required calculations into a small fraction of a physics frame, i.e. it will almost certainly include similar restrictions on "down". Remember that most games using wheel physics don't allow completely free form construction, so a single fixed "down" per wheel model is a perfectly reasonable design compromise for even the best of wheel physics libraries, especially if it leaves more physics computation time available for better friction+torque+steering+suspension modelling. Wheel physics on consumer PCs, even very high end gaming systems, will always involve approximations and some compromise. Maybe this library will surprise me, and has some great trick to improve on that normal simplified model without a huge performance hit, but I'm certainly not expecting miracles on that specific point.

For the greater good, you really need to be looking for mod wheels that are suitable for your purpose, instead of asking for behaviour which would significantly hit the physics performance for everyone who uses the wheels in their intended way (i.e. correct attachment rotation). The wheels you would like to have, in terms of low ride height, are quite possible even with Unity 4's standard wheel colliders, you just need to find a part that actually matches your needs instead of trying to use the wrong part in an unsupported way.

I would advise everyone to keep their expectations relatively low on this, then be pleasantly surprised if the new wheels are a huge improvement or deliver extras. If you set high expectations at this early stage, you could be setting yourself up for a big disappointment. Squad are being forced to change to a new wheel module because Unity 5's default wheel colliders are not fit for purpose, and not because they needed or necessarily desired vastly more accurate wheel physics, or at least that's how I interpret it. KSP can't let the wheel physics dominate the physics engine, they have to co-exist with all the other physics going on at the same time. That may well force Squad to configure their new wheel modules in a fairly "simple" mode. The new wheels will very likely be a good improvement over current Unity 4 wheels, but keep your expectations fairly well grounded or risk disappointment.

The main improvements I anticipate is better modelling of friction and suspension, which is an area that the Unity 4 wheels don't handle in a terribly sophisticated way.

[Grumman]

I wouldn't count on that changing. There's an extremely good reason for that behaviour in terms of physics performance. Wheel collision has to be evaluated every physics frame (many times per second), for each active wheel. That particular simplification is a very necessary part of typical wheel physics modelling, by casting a ray in the direction of the wheel's "down" (which is not the same thing as gravity "down") to find the terrain or object that it should be colliding with. It saves a significant amount of computation over actually trying to accurately model the collision of a cylinder with uneven terrain.

Doesn't the game already need to accurately model the collision of cylinders with uneven terrain? Creating a specific type of cylinder that adds another variable to its tangential frictional force vector calculation does not seem like something that would require very much additional calculation.

[Murph]

Doesn't the game already need to accurately model the collision of cylinders with uneven terrain? Creating a specific type of cylinder that adds another variable to its tangential frictional force vector calculation does not seem like something that would require very much additional calculation.

If you mean collision of a miscellaneous cylindrical part with terrain, that's completely different to a wheel collider. In that case, it certainly does not need to accurately model the collision, as a very rough approximation is quite sufficient to produce a "good enough" result. The behaviour I described, using a single ray cast in the wheel's "down" direction, is what the Unity 4 wheel colliders are forced to do, because actually modelling the interaction of a cylinder with terrain is too computationally expensive, if you need the end result to behave roughly like a wheel would behave and maintain a high frame rate.

That calculation is significant, when you need to perform it e.g. 100 times per second (4 wheels and 25 physics frames per second, just as an example, I can't remember KSP's physics frame rate), alongside many other physics calculations and the remainder of the game's processing. The concept is simple enough, but actually creating code which runs within a small fraction of a physics frame, that's quite different to the concept.

For most games, there's simply no need to accurately model complex cylinder/terrain interaction for wheels. A simple ray cast, modelling the wheel more as a thin stick pointing downwards, can give an excellent approximation and saves a significant amount of computation. In essence, it distills wheel physics down to just the important part of real wheel physics. With a real wheel, looking at it in an instant frozen in time, there's a small flat square which interacts with terrain, and all the important behaviour occurs at that small flat interaction (discounting stuff that is completely out of scope, such as deformation of an air tyre).

Edited June 14, 2015 by Murph