Building a New Universe - KSP Discussion at Unite 2013

[Apollo13]

This is an interesting presentation by Felipe in which he discusses the challenges of using 32-bit Unity engine to deal with distances in KSP that really require 64-bit precision.

If you haven't seen it, pop a cold one and sit back.

As a programmer/developer for over 40 years, this was definitely cromulent to my interests.

Edited September 24, 2013 by Apollo13

[HarvesteR]

Thanks for posting this. It's very much dev-focused I know, but there are some good bits of information in there that should hopefully be interesting to everyone.

Cheers

[rodion]

This rules, well worth sitting through the whole thing. Super informative on the game dev process and often funny. Especially interesting to see cameos of the earliest iterations of the game, down to 0.1.

[rkman]

Thanks for the heads up. Very interesting.

[ArmchairGravy]

A great look at what's going on under the hood. Thanks!

[Dispatcher]

Watched it on the day of You Tube release. I'm not much of a coder, but it was great to see how Squad overcame obstacles and persevered to get the game as far has it has come. I think these guys (Squad) are geniuses! (Moving the universe instead of "you" to reduce errors, wow.)

[Deep silence]

That is a great video; squad devs should be proud of their work!

[Technical Ben]

Thanks for posting this. It's very much dev-focused I know, but there are some good bits of information in there that should hopefully be interesting to everyone.

Cheers

It was very very interesting. Also, I know know why my game "jitters", it's "frame shifting". I'll allow the jitter if it allows for the awesome game.

Loved the details on how you first made the game and the info behind the technical hurdles.

Watched it on the day of You Tube release. I'm not much of a coder, but it was great to see how Squad overcame obstacles and persevered to get the game as far has it has come. I think these guys (Squad) are geniuses! (Moving the universe instead of "you" to reduce errors, wow.)

And if Einstein is right, that's exactly how THIS universe works.

[FellipeC]

Now I know my ships indeed works like the Futurama`s ship engine =)

[Guest]

Great insight into this game's development, thanks for posting that.

[TMS]

Neat stuff. Thanks for sharing.

[pxi]

Saw it posted on reddit a few days back. Very interesting indeed, always nice to get a glimpse under the hood!

[Masked Turk]

This video's given me a much greater respect for the game developers, for knowing what technical challenges they've faced with features we might otherwise take for granted as 'doable'. Gives me a bit of context when I internally wish they'd add X, Y and Z to the game.

Just a shame they ran out of time to wow the audience

[DAVIDESCOTT]

This is an interesting presentation by Felipe in which he discusses the challenges of using 32-bit Unity engine to deal with distances in KSP that really require 64-bit precision.

I don't think these issues would be fixed by the 64-bit unity engine so its a bit deceptive to describe the video that way. This is just a float vs double issue and won't change with 64bit Unity.

The fact that Unity choose to use 32bit floats instead of 64bit doubles is probably dictated by the graphics card hardware which has traditional supporting float but not double arithmetic.

In fact any floating point arithmetic done on general purpose x86 CPUs is promoted to an 80bit extended precision type within the CPU registers and then down-converted to a float or double when you store it back to a general purpose memory address. Therefore programs written for 32bit CPUs will generally use 64bit doubles because it is just as fast and more accurate. The only reason to not do so is if the application doesn't call for that level or precision or range (a rare occurrence these days) or a need to interact/shift computations off to another processor (ie your GPU).

[Aiel_Wolf]

A nice video. It's a shame that you had to skip over those last few points. A lot of those last few minutes seems it could be relevant to us. I would love too see what you had planned to say in the bits you had to skip. It almost seemed like you could have had double that 1hr slot and still not enough time to say everything that you wanted to say, let alone answering questions.

[asmi]

I can't help but notice that the bulk of problems they had to overcome were caused by Unity engine itself - and by themselves these are not that big of a problem. What they call "origin shift" is known in the industry as "view space" and is used since...forever (typical pipeline is - local(model) space -> world space -> view space -> clip space -> normalized clip space). It takes one matrix multiplication to transform coordinates from any of abovementioned spaces into another one.

[DAVIDESCOTT]

I can't help but notice that the bulk of problems they had to overcome were caused by Unity engine itself - and by themselves these are not that big of a problem.

I don't get the whole dumping on Unity thing that is going on. Its not Unity's fault that the GPUs are designed for 32bit floating point arithmetic. It is the limitation of the GPU that dictates that the game engine work predominantly with 32bit models, geometry, and physics.

About the only thing you can fault Unity for is not providing a view space pipeline API which forced the developers to roll their own.

Edited September 24, 2013 by DAVIDESCOTT

[asmi]

I don't get the whole dumping on Unity thing that is going on. Its not Unity's fault that the GPUs are designed for 32bit floating point arithmetic. It is the limitation of the GPU that dictates that the game engine work predominantly with 32bit models, geometry, and physics.

About the only thing you can fault Unity for is not providing a view space pipeline API which forced the developers to roll their own.

No, this is incorrect. I had exact same problem in my own engine, and successfully solved it.

First problem is with graphics: "Conventional" graphics pipeline follows this order for coordinates transformation: model space ( * WorldMatrix) -> world space ( * View Matrix) -> view space ( * Projection Matrix) -> clip space ( perform "W-divide") -> normalized clip space. This order used to be mandatory until programmable pipeline stages (via vertex/pixel shaders) had been introduced. Naturally, KSP's problem is a combination of two factors:

1. Unity takes care of calculating these matrices. BUT - it uses single-precision math for that.

2. Their world-space coordinates are HUGE while view space are small. So what happens is that model space coordinates (ones that were created in model editor) get multiplied by HUGE number (which leads to loss of precision), and then is multiplied by another HUGE number (to bring them back into view space, which leads to another loss of precision).

The problem can be trivially solved by pre-multiplying World and View matrices using double-precision and only than converting it to single-precision as needed by GPU. But I don't know if it's even possible at all to force Unity to use provided World-View matrix, as due to (1) it's Unity who is responsible for doing so. However, this is a trivial thing to do in your own engine since you have full control over the GPU pipeline.

Second problem comes from physics engine, which operates at single precision, but for obvious reasons is required to work in world space, and so will incur big loss of precision. Again, a problem that is forced upon devs by Unity, as there are physics engines out there (even free ones!) which works with either single- or double-precision, so essentially eliminating that problem as well.

So let's see - too biggest KSP's issues are induced by the engine...

Edited September 24, 2013 by asmi

[Jstone39]

whoa whoa whoa since when have we had .22?

[HarvesteR]

About the only thing you can fault Unity for is not providing a view space pipeline API which forced the developers to roll their own.

No engine that I know of does that. The sorts of issues we had to work through with KSP would have been there regardless of Engine choice, unless we had decided to build our own, in which case we'd still be doing that and KSP wouldn't exist.

Cheers

[AmpsterMan]

No engine that I know of does that. The sorts of issues we had to work through with KSP would have been there regardless of Engine choice, unless we had decided to build our own, in which case we'd still be doing that and KSP wouldn't exist.

Cheers

It'd be awesome of you could male a custom engine for KSP 2 and then license the engine for other companies to use in their space sims.

[Tw1]

It'd be awesome of you could male a custom engine for KSP 2 and then license the engine for other companies to use in their space sims.

I'm not sure about the whole need-for-another-engine thing. Unity gives some awesome advantages for mod making. And there's a decent free version. No idea if other engines are as convenient for people who just decide "I'm going to make a mod" one day. And mods are a major part of this game's greatness.

It was very interesting seeing all the little work arounds, and how all the things are set up. It's so complex!

Thanks for making the system so easily modifiable.

[oberlerchner123]

Very interesting. I knew this game had issues with floating point precision errors but not to what extend and how many of them you fixed and how.

Cool to get to understand some of the inner workings of this game.

I see how having it's own engine would be useful, but yeah I'd imagine that would have taken an unimaginable long time, especially seeing how the dev team started small.

Anyway I love the game the way it is, it's a lot of fun, and has a way of making me feel smart or dumb when something goes right or wrong more than any other game ever.

Maybe some day we'll get KSP 2 64-bit with multiplayer.

[Majiir]

I enjoyed the talk. Thanks to both of you!

Harvester, there was an item you skipped over near the end that I thought was interesting. You had a slide reading something like "repeat until indoctrination: mods are not competition". I wondered if you could elaborate on that (or just say what you'd planned to originally). Have there been times when mods felt like competition? Getting more broad, how have mods influenced your development methodology or even specific points in the game's development history?

Cheers,

Majiir

[Brofessional]

Is this from .22? I haven't been to Duna much in .21 but I don't recall it looking like that.