[Music] [Applause] [Music] All right, well welcome everybody. My name is Felipe. I'm a lead developer on Kerbal Space Program, also known in the community as Harvester. And joining me today is Mike Elin over there. He's our

gaming tools developer, and we're gonna talk about KSP today. And we've just got here and have no idea what the heck is about. Kerbal Space Program is a game about running your own space program, so you get to build spacecraft in a construction facility by assembling

parts together and later launch your proud spacefaring vehicle into space. And one of the big things about Kerbal Space Program is that failure is part of the fun, and there's quite a lot of failure along the way. But once you manage to get up there, you get accurate

orbital mechanics and an entire solar system to explore. So you get to land on other planets and moons, plant your flag, walk around the surface, build space stations, and construct spaceships by docking vessels together in orbit. And ultimately, you're managing your entire space program in career mode, which is

what we're developing at the moment, because Kerbal Space Program is still very much in development. We've been following this iterative development method, so we do, we started out doing three-week development cycles, and every three weeks we put out a new version which was supposed to be stable, so our

focus is always on, at the end of each release cycle, we end up with something that's playable, even though it might not be complete, it's stable enough and it represents the concept as well as it possibly can. So on that screenshot, you see KSP version 0.3. We have

a placeholder parts placeholder in UI placeholder terrain really solder just about everything and from that version which the max was when we started actually going full-scale with it because up until here we were testing out basic mechanics and everything and KSP version zero point four was when we

started actually tackling the problem of doing terrain on a massive scale and we quickly ran into floating-point issues because I don't know if you ever tried but if if you just move an object in the scene very very far away you start getting all sorts of crazy effects and

that's because you really require very large numbers to do a space simulation and a 32-bit float can only hold so much so if you've got a relatively small number you get all the rest for your decimal places and it's accurate enough but if your values start getting starts

getting like really really high then you need to start losing digits on the right-hand side of the decimal point which means the higher you go the more precision you lose and eventually things start to break down so how far can we go with 32-bit floats just launching a

ship from the scene origin say the launch pad is at the origin and about 20 kilometers out you can see some jittering already this is from version 0.3 you can see it's already slightly jiggling at 100 kilometers out it's very

visible I wasn't doing anything this is pure jitter and if you go much further out things start getting like really bad so we need to do something about that because really there's still a long way to go here so the the solution for this is actually well known in the year 3000

basically you don't move the ship, you move the universe around the ship and this is called floating origin so basically how it works is we set a threshold which in our case is six kilometers and if we move the ship past the threshold we grab everything the ship meshes, scenery,

particles and we move it back so that the ship is back at the origin so what this lets us do is that we can't really work around having to use 32-bit floats so the physics on a 32-bit transfer matrices or 32-bit so it's not really

about precision it's about resolution so if we can stay near the origin we've got enough spatial resolution to have a decently accurate simulation so the idea is that we're always near the scene origin and everything around us can be built or rendered with nice

enough precision and stuff that's far away will slow jitter but it's far away so well it doesn't really matter as much but we still do need a way to hold that data in high precision and for that we do need to use 64-bit doubles so what we

did is we created clones of vectors and quaternions called Vector3D and QuaternionD which do exactly what Vector3 and Quaternion do but with double precision values inside they even have the same methods and everything so we can do everything we did with you get

any data types in there with precision so all our orbit maths and such calculations are done in double precision and we store those in our controllers for celestial bodies and orbits and stuff and then we assign them to transform position continuously so as you approach an

object you this object is actually approaching you and it's approaching the high-resolution space around you so this is how we manage to keep floating-point imprecision relatively under control but it's really an ongoing battle with it because we found floating-point issues just about anywhere one of the most

famous cases of course is a space kraken which is not because we're just going very far we're getting there very very fast so the thing with the space kraken it's a floating-point imprecision also effects your velocity because velocity is also a 32-bit vector so and because

our ship it's not really just a single object it's made of several multiple connected rigid bodies each one of them has its own velocity in it each one is getting truncated and it's sewn different ways so the symptoms of being attacked by the Kraken include phantom

forces that steer you off course and this is the first manifestation as you go faster you completely lose control and eventually things start coming apart so a solution for that is Kraken's Bane yes we did defeat the Kraken eventually and it's basically the same

thing as floating origin but for velocity so what we did here was to create this reference frame which absorbs the velocity of the vessel so that means we set a threshold for a maximum velocity you can have what physically and after you exceed that threshold we zero out the velocity of

the vessel and we update that and we pass it along to the reference frame so instead of the ship moving very fast we have this reference frame which holds double precision velocity value which moves everything else the other way around so that way and we constantly keep that updated so as forces act on

the vessel like gravity and your velocity changes we're also always zeroing it out and applying it to this moving velocity frame so when you slow back down whatever velocity still remains on the frame we apply it back to the vessel and it uh it resumes normal

physics so that leads to see the setup of the universe and how we put it all together so the big thing with KSP and how it's set up is that we've gone to scenes and some scenes are basically scenes within a scene on different layers so each scene is rendered by its

own set of cameras so they all exist in the same space but they're rendered differently and they all can have their own reference frames so in KSP we have three of those we have local space scaled space and internal space and local space is our one-to-one

scale main game environment where you have your scenery and all the ships parts they all live in local space and this is actually the scene orientation the Kerbal Space Center is actually sideways because it sits at the equator of Kerbin so world space is a generally

meaningless term to us now and scale space is or when you when you're sitting at the launch pad and you look up at the moon what you're seeing is actually the scale space version of the Moon which is a 1 to 6,000 scale miniature of the

solar system which we use because it's much easier to manage these things on a much smaller scale so for instance Kerbin is only a hundred meters on scale space so that gives us a much more usable area to work in and sit and do stuff like rendering the

atmosphere and rendering orbit splines and things like that and skill space also doubles as a map to you, but I will get into that in a bit. Third one is internal space. Internal space is where we do our internal views, which are used both for the inside

cockpit view and the crew portraits you see on the bottom right of the screen. So sorry, so with internal space, we when you're looking at it from the inside, we render only the internal space that contains the Kerbal you're currently possessing and we remove his head as well, so you

can look around and the head mesh doesn't get in the way. And as you switch views, we switch internal meshes and we remove heads as necessary. And in the end, we put it all together like this. What you see on the back of the fruit of this

layer gets drawn first and that's a scale space rendering, which holds the the galaxy skybox, the the atmosphere and then the two metal ones are our local space. We actually had to divide it because even though we have the local space scale space thing going on, senior

you still too large to be rendered by a single camera so we have a lot of z-fighting issues and the way we worked around that was to have a new camera which renders everything from very close up to about five hundred units away and then we have the far camera which

renders from there on until it all fades away and then you get scale space. So on top of that we draw the UI or when you're in internal view, we draw the internal camera and what it renders, so it all renders on top of each other and

it composes into a single image so next up are the orbital mechanics themselves basically we had to make a big decision here of how we were gonna simulate orbits and we ran into several issues with physics and physics integration basically problems our physics our integration based and

integration means that you compute the state of an object based on its current state plus all forces acting on it so you figure out its velocity you figure out the time step and you move it forward but the problem with that is that the state of the object depends on

the previous state so errors tend to accumulate so what happens for instance if you're simulating an object orbiting a moon out in Jupiter so that object way out there on in the boondocks or floating point and accuracy is trying to do what it does but it's so

inaccurate that it's probably gonna fall out of the sky not to mention the moon itself being flung out and general mayhem like that so and apart from that you have issues with time warp because you either speed up time and you drop

frames and you lose accuracy or you simulate sub steps and you completely kill your computer trying to do a hundred thousand times warp factor so not very viable for us so this is why deterministic physics are cool so instead of the computing your your rigid

bodies through integration we run a two-body solver which is basically using another set of values and another set of maths to calculate the problem so the state of the object becomes a function of time you can figure out where something is gonna be just by passing in

a time value which means you get to do stuff like scrub time and time work becomes really very simple because all we need to do is multiply the ongoing clock by the single universal time value, and we can resume to save the entire system. So we don't need to save where

everything is out in order, but we just say one universal time value and the whole solar system adapts to it. So it's all persistent and very reliable, and there's no compromise in accuracy whatsoever because all you need is that one time value. And it's fun as well because these

textbook type physics are very much what you find in a physics textbook. So when you're trying to teach about physics and stuff like that, usually it's well, look at how it went, but it's not really like this because you have to account for a

drive, you have to account for gravity not being uniform and all that sort of stuff. In case people decided to do away with all that, and really what you see is what you get because perturbations in practice just tend to look like noise. I can just imagine people coming to the

forums complaining like, 'Hey, my space station dropped out of the sky and I have no idea why.' And we say, 'Well, that's not a bug, it's a feature.' Well, it's kind of hard to explain a thousand times around. So it's nice that we don't, we have no

difference between the actual trajectory and the predictive one because it's solved using the same math. So the big trade-off though is that there can only be one gravity source at a time, so that becomes a bit of a thing that we have to work around. And we do that by using the

concept of spheres of influence, so we do multiple gravity sources one at a time. So basically we figure out what the dominant celestial body is based on where you are and if you're inside its sphere of influence, and we calculate your orbital parameters as you transition. So that's how we do being

able to go around and orbit around a moon and stuff like that. So these are your orbital parameters. We use them in two ways: we calculate them from position and velocity for vessels, and for planets and moons they're manually defined. So we basically build out the planetarium like

this by just setting the orbital parameters for each planet and for each moon, and we let them orbit based on the game clock. And for spacecraft, we have what became known as the rail system, which is basically the same thing for spacecraft. But the thing is here for spacecraft, we

are running physics, but at some points we have to stop using physics and switch to the deterministic system, which is something we call going on rails. What happens there is that all rigid bodies go kinematic, then your controller switches to driver mode instead of just

tracking, and we calculate position and velocity from a two-body solver instead of physics. And the same thing happens in reverse for going off rails, which we may call rigid bodies non-kinematic again. We get the velocity from the two-body solver and we basically throw the vessel

back into physics, and then your Wii controller global goes back into being just a tracker and updating its own orbital parameters from the vessel and just watching it happen. And then next up is drawing orbits. So to draw the splines, we needed something to draw a line, so we

use a plugin called electricity to do the spline drawing and basically we build the orbits plane just by using the solver we sample it along its course so that gives us a very nice way to just to give Kerbal an array of points by sampling the orbiter as it goes and then we

render it out in scale space so skill space then doubles or map view so when you hit em and you zoom out to the map what happens is we disable the local space camera so you don't see the scenery and you don't see the vessel and

we fade in the orbit splines and then we disable the skills camera script which is basically just a little script that tracks the local camera and applies the scale factor to it and on the same camera we enable the map camera script so that's how we do the map view just by

switching the camera behavior and this map view was really important because the big thing about KSP is that it needs to be approachable and the problem the main problem I see with rugged science is that uh you have a severe lack of situational awareness you

really don't know what's going on because it wasn't like a real easy intuitive way to see it so the biggest challenge I think in KSP was this was how to convey what's going on in a way that's visual and informative but

without just dumping a lot of data on the player so the map is fully 3D and you're free to move around and you're free to focus on different objects and view your orbit from every angle so that way you get this much more intuitive

understanding of what's going on just because of the way it's drawing in 3D space and you can move the camera around and see it from different angles, so we only show numerical data when it's really needed. So this is why we have

things like "sorry, too early" when you get to, when you hover over the nodes on the map view, then we show what the node is and what its values are. So we're not flooding the players with numbers all the time because otherwise it's very easy to just fill the screen up with

numbers and end up with something very unattractive. So finally, we patch orbits together to do, to do the full trajectory display. Now, I had thirty more slides on this and I could go on and on, Leslie, but uh, it's not gonna be enough time to cover how we do

this, but basically we use a rail system to predict where you're gonna be and where each planet is gonna be by the time you get there, and from that we figure out what your next orbit is gonna be inside the sphere of influence of that other body, and so on and so forth

until we either reach some sort of limit or we reach an orbit where you can't, where you don't find I need more encounters or escapes, and we display that using different time reference frames. I call it, you can see that as you encounter the moon, you don't really see

your orbit around the moon, you see it orbit around the moon in relation to Kerbin because the moon is also moving. So we're really essentially trying to show 4D data in a 3D space, and there was a good deal of head-bashing to figure

out a way to show this in a way that makes the most sense, yet eventually settled with this, which is that we show your orbit locally for the planet you're orbiting, and if you encounter a planet somewhere ahead, we show that or a bit in

relative frame, which is what we call that. Each point is sampled at the spot it's gonna be at that time, so that gives us some nice squiggly lines where you can see things like how you encountered the moon, loop around it, and jump back. So

that's basically how we do it. Forgot those. And so you know this is another interesting part of the game that I, you felt was worth showing, the reentry effects and how we did that. Basically, the problem with reentry effects was that we wanted the ship to look like it

was catching on fire, and you could see the plasma, like looking the shape as it went. But the big problem with this is a on more conventional game, you'd have this effect done for the specific ship and have another version of it for another ship and so on.

But we don't know what the ship looks like. We can just build anything. So we needed to find a way to do this effect that would support any configuration of something you might build. And apart from that, we ran into another problem, which is no one really knows what reentry

effects look like. There's a lot of image images on the internet if you just look for it, but you can see that of all of these, they're all artists' renderings. None of them are actually a picture. New ones that were you can't find like a

Really nice picture with what the reentry effect looks like, so in the end we settled in trying to achieve this look, which we broke down into two components: the heat glow and the flame trail. So for the heat glow we tried a couple of things, and we tried, we thought about maybe an

emissive texture or something like that, but the emissive map was tricky because we don't really know the orientation of the ship, so which way of it is actually facing the incoming air stream, and well, eventually what worked best was to just use a

light, an orange light placed along the velocity stream, so that was much easier actually. So the flame trails were trickier. The first attempt we tried to use God rays, and look, it looked close to what we wanted to achieve, but it doesn't work unless your scene is a black

backdrop with nothing else on it. This doesn't work at all, so we'd get flame trails on the UI, on everything, so, and it generally broke down. So the second attempt was something more. I remembered seeing this effect for first shaders and free shaders work by having, by drawing

the same object again and again using shells, and just having a transparent texture, and I thought, well, maybe we can abuse this in some way. So I got a free shader and started tweaking and modified the shaders, appreciate it gave us this result. Basically, we draw a multipass shader and

all of the shells are offset progressively along the, well, the opposite of the velocity vector, so they're running away from you, and we, and on top of that, on each pass, we run slightly different parameters for opacity and color and things like that, so that started to look real nice, and we

do that we render it out in the game by using replaced shaders and an effects camera on top of all the other cameras we already had so um it's just one more camera at that point so we rendered the ship as normal and then we run the

effects bus which renders it again with a replaced shader and but the problem with that is it worked a little too well so every face would be on fire even back faces so that didn't look really right we get the the burning window effect as it was named by the community so the way

we solved that was to do essentially shadow mapping we got a camera along the velocity vector that renders the ship whether that flexure and we projection map this step texture onto the ship and then on the shader we can check if the for each vertex if the depth of the

vertex matches the depth on the map and if it doesn't we occluded and if it does it means that it's actually exposed to the air stream so that way we can mask off the areas that are occluded in they're not on fire and that pretty much

solved the issue and then lastly we use an animated texture map to actually modify the extrusion length of each pass that required us to use a vertex texture read which thankfully was possible on Jade 103 so this screenshot doesn't really convey what actually happens

there is a video later on and we actually got a nice bonus feature from this we got just by tweaking the parameters and the way we scaled the offsets we got to do mach effects which basically use the same approach just with tweaked values so here we've got a

little video of the orbiting space station in the name of science and I'm not getting into wait why is this not playing ma'am sorry minor technical difficulties oh it's because we're not connected but they didn't get on the Wi-Fi that we

we're not anymore um might have to skip this board sorry if we can get the connection back later we'll come back to it so next up is the terrain and for that part we we've got Mike who is at fault for all that so testing hello

so our terrain system is called the procedural quad sphere or PQS basically it's a method we use for rendering the terrain so we've got some sample shots here's a nice little mountain range and some planes in Kerbin here's another mountain range and some lovely trees

scattered here's a view from KSC showing some more mountains actually so the aims of the system first of all we needed to ground to a bit level of detail system pretty important in a space game we needed planetary scales Kerbin is 600 kilometers in radius which is a couple

of million square kilometers we need to have a huge variation on the planets themselves and between the planets and something that's not you know immediately evident but it's quite important is we need to be able to sample the terrain without building the

mesh or building colliders so we can raycast against them this allows us to do lots of things radar altitude and collision on objects which we're not in orbit of so for other ships in the solar system so what is a quad sphere

It's a sphere made of quads. First of all, we start with a distorted cube base, and then we use a quadtree subdivision to get the level of detail. Increases, so what what does this look like? Here's something which will never happen in the game. It's a minus one sphere. This would

never happen because we never store the planet like this, so I've had to mock it off with planes in Unity. Each each plane is 16 by 16 vertices, then we do a few operations on it, and we end up with the level 0 sphere. So this is the lowest

resolution thing that we can have in the game. As you can see, the 6 planes are now mapped to the surface of the sphere. Here is one of the planes selected. You can see it's a nice curved shape, and they all match up edgewise, so it's level 1.

We've got 4 times the number of vertices here, and you can see that the same plane that we had in the other one is subdivided into these four planes. And let's move to level 2, so we can see that the upper-right quadrant we had in that

plane has now been subdivided into 4, giving us 4 4 times as many vertices. Level 3, I'm getting quite a lot of vertices now. Level 4, pretty hardcore. And level 5 is pretty black. So how many vertices have we got? Kerbin, 600

kilometers radius. So the vertex resolution is 75 kilometers in a level 0 sphere. 1,500 verts, quite handleable. The level 5 SVC is 2.3 kilometers vertex resolution, but it's 1.5 million, which is pretty extreme.

Now most fears run up to level 10 in the game, which if we rendered it straight out would be 73 meters resolution, which is adequate for the game but it's 1.6 billion verts, which Unity would not render surprisingly. So we need to use

adaptive subdivision, and to do this obviously we need to use distance to the camera. We use various types of distance; we've obviously got the linear distance, but we've also got the Great Circle distance around the sphere, and the algorithm to calculate the subdivision is quite complicated. I'm not going to go

into it, but you asked me later, I will do. Quite important is only subdividing ourselves one level higher than our neighbor quads. This is quite important because if you start to have four neighbor quads, it gets quite complicated, and we have the next point, which is we

need to avoid cracks. So here's a level zero to ten sphere. You can see that the where the subdivision changes, it's only one subdivision level higher where the tiny white circle is on the left. That's where the cameras placed, and under that will be subdivision level ten on the

Unite 2013 - Building a new universe in Kerbal Space Program

Unity is the creator of the world’s most widely-used real-time 3D (RT3D) development platform, giving content creators around the world the tools to create rich, interactive 2D, 3D, VR and AR experiences. Our 800+ person engineering team keeps Unity at the bleeding-edge of technology by working alongside partners such as Magic Leap, Google, Facebook, Oculus and Microsoft to ensure optimized support for the latest releases and platforms. 

Apps made with Unity reach 2.7 billion devices worldwide and were installed more than 24 billion times in the last 12 months. Unity is powering the real-time revolution, expanding beyond games and breaking into other industries including automotive, film, architecture, engineering, construction, and more. 

You can download Unity from our website: https://on.unity.com/3FSLbKn
Facebook: https://on.unity.com/40zifiE
Twitter: https://on.unity.com/40h2dtS