Development Update: KSP and Unity 5

Hi,

Since we didn't have a full dev note this week in light of the PS4 announcement, I figured I'd write up some lines about what's currently going on on our end, which is for the most part related to the Unity 5 port at the moment.

It's worth mentioning though, that our moving to U5, which I think is fair to say is something everyone has been asking for quite a while, has been largely sped up by our collab with FlyingTiger, who are developing the PS4 version. The first step for them was to move the game into U5, and because that was something that affected the entire project, we felt the best way to go about it was to work together on upgrading the project, so the PC version wouldn't be stuck on Unity4 as they moved on. So contrary to popular belief, the move into PS4 is actually giving PC development a boost, not hindering it.

Anyhow, let's get into about what's going on development-wise.

First off, the biggest hurdle/opportunity we came across was the game's UI. The current UI implementation (not design, mind) is, well, let's say it's not my favorite part of the project... The lack of a robust native UI toolset in U4 and earlier meant that over the course of development, we ended up with multiple different, sometimes conflicting UI systems working alongside one another. Unity's OnGUI code-driven UI, EzGUI, and the SSUI system I wrote back in v0.3 or so, all these systems were being used at the same time, each drawing their bit of UI, and trying not to step over the other's bits.

Re-doing the UI was something we all wanted to do here, but the amount of work it would require was, to say the least, discouraging. That's all of the game's UI we're talking about. From part context menus to confirmation dialogs, to flight gauges to settings screens... all of it needs to be redone. Not a small task by any measure. So it's no wonder we weren't exactly in a hurry to deal with that before, even more so because before Unity's new UI system came along, the idea of consolidating UIs meant choosing one of those systems I mentioned earlier... so we wouldn't be upgrading to anything superior then.

With the new UI system in U5 though, this became a much more interesting notion. Unity's new UI combines the best features of the many UI tools out there,into a flexible, sleek and very powerful all-around system. Good, but it still meant redoing the entirety of the game's UI.

The final push came from the PS4 porting side. PS4 has its own set of tech requirements, and our 'eclectic' UI implementation was evidently not quite up to par with those reqs. For the past weeks then, we've been working on a total revision of the game's UI. Currently Jim (RomFarer), Mike (Mu) and DJ from FlyingTiger are assigned to that enormous undertaking.

On my end, I'm tasked with the shaders and physics side of the U5 upgrade. Shader-wise, we had a few broken ones here and there because of upgrade issues, which were for the most part easy to fix (DJ helped me out there a lot too, he had been plugging away at it while we were still in exp for the 1.0 release). The ones that were most complicated were the terrain shaders. U5 compiles shaders differently, so that meant some of our terrain shaders were now above the SM3 limit for interpolators. A shader interpolator is the process by which the GPU figures out what a pixel that sits in the space inside a triangle ought to look like. It does that by (as the name implies), interpolating values from the surrounding vertices, which were calculated earlier, to compute the final colour of each pixel... Anyhow, the problem was that SM3 (DirectX9) imposes a limit of 10 interpolators, and with U5, we were now using 11. That wasn't all bad though, it meant we just had to reduce the shader by one interpolator, which I was able to do by moving some bits of the vertex code into the pixel program, and just pack the data that those bits needed to function into already existing interpolators which had one or two unused channels. It seems if you have a vector interpolator, it doesn't matter if it's a 3D or 4D vector, it will take up one interpolator. That means you can pack extra data into the 'w' axis of 3D vectors and cheat yourself some extra headroom that way.

Shader issues dealt with then, I moved on to the physics. These were largely modified in U5, and at first sight, it appeared we were in for some real trouble, because all our joints were now less stable than before.

Turns out, U5 opened up the range for some joint springs, so fortunately, all we needed to do there was up the stiffness of all joints again to have the same behaviour as before.

Now, however, I ran into one real problem: The wheel colliders in the new PhysX are much less stable than their older selves in U4, and all our wheels were now effectively non-functional.

Wheels are deceptively crucial things. You don't realize just how important they are, even to a game taking place mostly in space, until suddently they stop working. The broken wheels meant all spaceplanes would break up immediately on spawning, and of course, those that survived had very little chance of even getting up to speed on the runway, let alone making it off the ground.

The wheels were not something we could apply a quick fix for. This needed a comprehensive new solution. Fortunately, this solution already existed, and just in time actually. A package called Vehicle Physics Pro (VPP in short), which is a more realism-focused vehicle simulation by Edy, who created Edy's Vehicle Physics, a widely used vehicle asset package, but more gameplay-focused than VPP, was just recently made available in 'early access' form. It's still not in the Unity Asset Store, as it's still being developed, but the bits we needed for KSP were all there already.

So, I got in touch with Edy, and got us an Early Access license to VPP. Edy has been remarkably helpful also. He even wrote a wheel controller specifically for KSP in advance.

VPP is primarily focused on cars and car-like vehicles, though, for normal-ish games where vehicles are a single rigidbody and gravity points 'down'. KSP is, well... not normal in that sense. There are no 'vehicles' as such, because every part has its own rigidbody, and gravity... well, let's just leave that by saying it doesn't point down, and not get into discussng what down even means in KSP.


KSP's rather unique requirements meant that VPP also needed its set of modifications to work properly. For the most part, that was just a matter of replacing any bits of code that worked under the assumption that Vector3.up actually represents something meaningful in the game world by our FlightGlobals.upAxis and friends. Then, we also needed to contend with the vehicle setups themselves. In KSP, we can't rely on vehicles being set up as a single rigidbody. Each VPP 'vehicle' for us, just represents a single wheel or landing gear part, which is attached to others by joints.

In practice, that means the simulation of suspensions and tire friction (which VPP does fantastically) can't rely on the vehicle's rigidbody mass to calculate the load a wheel is supporting (aka the 'sprung mass' of the wheel). Happily, there exists a law in physics called Hooke's Law, which states that the force exerted by a spring varies in direct proportion to its compression. That is to say, we can figure out how much weight a wheel (and its suspension spring) is supporting by looking at how compressed the spring is.

Replacing the rigibody.mass bits in the VPP tire friction code with this 'trueWheelLoad' value made all the difference. The wheel tire friction and resulting traction are now correctly simulated as the weight shifts and changes in the vessel on top of them.

Ok then, we now have a functional solution for wheel simulation, but that is still far from saying we have functioning wheels in KSP. The wheel part modules had all been written, long ago, to work with a simple Unity wheel collider component. That means all our wheel modules are now essentially obsolete, and have to be rewritten basically from scratch.

Well, it seems 'rebuilt from scratch' is the phrase of the month here, so I decided to go ahead and do just that, which was something I had been wanting to do for quite some time.

When we wrote the first landing gear components, IIRC, part modules didn't even exist. A part could be either an engine, or a fuel tank, or a langing gear, and if you needed something that combined any set of behaviours from those (like a wing that carries fuel), you had to write yet another subclass of Part to do that. Part Modules then came along and changed all that, but not before our existing landing legs and gear bays had already been written under the old paradigm. So when rovers came around, after modules and all that, they were given yet another set of code that basically did the same thing again.

As a result, we ended up with part modules specific to rover wheels, other modules for landing gears (with retract/deploy animation control built-in), other modules for landing legs, none of which could be combined properly without creating a despair-inducing tangle that would drive a battle-hardened developer to drink in less time than it would take the resulting mess of physics objects to come to rest after jittering themselves to bits.

Needless to say then, I've been wanting to write a new, modular, all-purpose wheel system for some time now, and the move to VPP wheels were the perfect opportunity.

I'm currently working on this now. I've created a set of modules that work together to simulate different aspects of any wheel. One base module creates and manages the VPP wheel component, then other modules hook in and manage their specific parts. We have modules for Steering, Suspension, Brakes, Drive (motor), Damage and Deployment, each doing no more and no less than their jobs. Setting up every wheel type in the game then should become just a matter of plugging in the features that your wheel needs. Static landing gears? Just omit the deployment module. Want steering? pop it in. Rather steer it as a tank? set it up with a differential drive steering module instead. Also, don't forget the brakes if coming to a stop is part of your mission profile.

There is still a lot to do there though. At the moment I'm working on the suspension module. This one is interesting, because suspensions are tricky things in KSP. You can't just set up the springs with fixed parameteres and leave it at that. Unless tuned to the mass they are meant to support, suspensions are pretty useless and can make a vehicle even less stable than if it had none. And in KSP, we can't ever assume we know anything about the vehicle sitting above the wheels.

So, instead of defining suspension parameters by the usual spring and damper values, I set up a scheme where suspensions have in their cfg definitions a 'naturalFrequency' and 'dampingRatio' values, which are then used to calculate the spring and damper internally, thus properly supporting vehicles of any mass. This means suspensions should be nice and springy no matter what sort of monstrous contraption you put together in the editor. If they are meant to break under too much weight though, that's not the job of the suspension module, we have a separate damage module for that.


Next up is steering. We did have steering already as a separate module, but it was incompatible with rover wheels (or was it rover-wheels only?)... anyhow, looking into it, I was suprised at just how much code there is at making a wheel turn either left or right. I reckon there must be an easier way to do steering... so that's up next on my to-do list. And while we are doing steering, we can set up the new steering system so all wheels on a vessel will behave properly and rotate to follow their own arcs (aka Ackermann steering), instead of just all just rotating to full deflection and leaving you to deal with drifting and doing donuts with an interplanetary rover.


Anyhow, that pretty much accounts for everything that's been going on on the U5 development side of things. In the meantime, Ted, Mike and the QA and Experimentals teams have been also working on bugfixes for the next update. Whether or not that update will be built with U5 already is still being discussed, but chances are that it wont' be. U5 still has quite a ways to go, and we want to deliver bugfixes as soon as we can. Conversely, we don't want to spam everyone with tiny updates unless they are for fixing emergency issues, so right now we are getting together a set of fixes and improvements that will make for an update worth downloading (and doing the whole deployment process over).



That's the story up to now. More news as they develop!

Cheers