Sign in to follow this  
Apollo13

Building a New Universe - KSP Discussion at Unite 2013

Recommended Posts

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 by Apollo13

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.)

Share this post


Link to post
Share on other sites
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. ;)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by DAVIDESCOTT

Share this post


Link to post
Share on other sites
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 by asmi

Share this post


Link to post
Share on other sites
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. :wink:

Cheers

Share this post


Link to post
Share on other sites
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. :wink:

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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. :P

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this