Developer Insights #4

[prestja]

https://www.kerbalspaceprogram.com/dev-diaries/developer-insights-4-ksp2-engineering/

Eeloo!

A close-up of Eeloo's gorgeous surface.

Spoiler

Image of what I believed to be Eeloo around the time of PAX East - but this is incompatible with the images above. New planet, then?

 

Edited June 12, 2020 by prestja
added image of Eeloo-like body

[Lewie]

That is beautiful....it’s good to see that people will now have more of a reason to visit lonely eeloo!

(if only eeloo in ksp could get a revamp...)

[Dirkidirk]

Nice.

[HCB-11]

Those textures tho

[Guest]

[Nightside]

shiny

[Superfluous J]

2 hours ago, prestja said:

Image of what I believed to be Eeloo around the time of PAX East - but this is incompatible with the images above. New planet, then?

More like old planet. Looks like they just used KSP1's Eeloo texture back then. This is a tangible sign of progress.

And yay for less than a month between updates!

[prestja]

12 minutes ago, Superfluous J said:

Looks like they just used KSP1's Eeloo texture back then

The cracked, reddish texture from PAX East is vastly different from KSP1's current Eeloo texture. I'm still under the assumption that this is a new planet/moon previously unseen. Regardless, both the new Eeloo and this mystery planet look wonderful!

[Cokeblob11]

I think the one from PAX is Eeloo, this one must be a new planet as I don't see why they would make Eeloo green

[TeddyBearBonfire]

40 minutes ago, Cokeblob11 said:

I think the one from PAX is Eeloo, this one must be a new planet as I don't see why they would make Eeloo green

Unless they mislabelled it, this is Eeloo. The image is named as such—look at the file names in the URLs: 

https://www.kerbalspaceprogram.com/wp-content/uploads/2020/06/Eeloo3-1024x859.jpg

https://www.kerbalspaceprogram.com/wp-content/uploads/2020/06/Eeloo1.jpg

 

And given how much attention they're paying towards real life data for aesthetics (going off things like the fuss they made about pink drive plumes derived of how it should appear in reality), it might be that they've changed the aesthetic a little based on the planetary composition. Pure speculation on my part, but it'd be a credible reason to my mind.

Edited June 12, 2020 by TeddyBearBonfire

[Gargamel]

I'm pretty sure that's a physical model.    If not, a darn good render, but with a weird surface texture and odd lighting. 

[Lewie]

Are those canyons I spy?

man, I can’t wait to see what the rest of the ksp2 planets look like...

[SOXBLOX]

uuouu! But seriously, this is cool. 

Also, can anyone explain this Spatial Scene Graph in more detail? What is it doing, how will it effect gameplay?

Thx.

Edited June 12, 2020 by SOXBLOX

[prestja]

52 minutes ago, Gargamel said:

I'm pretty sure that's a physical model.    If not, a darn good render, but with a weird surface texture and odd lighting. 

Hm, what's telling you that its physical model? The only tell I can see is that the second image has a small glow - and as we all know Eeloo has no appreciable atmosphere.

[Gargamel]

30 minutes ago, prestja said:

Hm, what's telling you that its physical model? The only tell I can see is that the second image has a small glow - and as we all know Eeloo has no appreciable atmosphere.

Like I said, it's either a photo-realistic render, or a model.   It just looks like the type of model you'd see in a museum/planetarium under bright display light.   If it's a render, then I'm hoping that's not the finished product, as the texture just doesn't look right.  I'm assuming they'll play with the lighting and such, tweak it a bit so it looks more 'organic'.   If it's a model, then I can only assume it's for the art department to use to create the finished product.  Either way, it does inspire me for the end result. 

[prestja]

10 minutes ago, Gargamel said:

Like I said, it's either a photo-realistic render, or a model.   It just looks like the type of model you'd see in a museum/planetarium under bright display light.   If it's a render, then I'm hoping that's not the finished product, as the texture just doesn't look right.  I'm assuming they'll play with the lighting and such, tweak it a bit so it looks more 'organic'.   If it's a model, then I can only assume it's for the art department to use to create the finished product.  Either way, it does inspire me for the end result. 

They did have a model of what looked to be Minmus in the developer update video.

[Kerbart]

Quote

Even on a modern CPU that can handle 64-bit math with ease, if we state that our lowest spacial resolution is 1mm (which, honestly, is not nearly small enough for what we do), the maximum signed distance we can represent is 9.2 Trillion kilometers, which is just shy of a Light Year.

Then again, 128-bit math will give you 35 decimals, which, at a 1mm resolution gives you about one million billion light years (maybe half of that if you need signed integers). My pocket calculator uses them, so how hard can it be?

1 hour ago, TeddyBearBonfire said:

Unless they mislabelled it, this is Eeloo. The image is named as such—look at the file names in the URLs: 

https://www.kerbalspaceprogram.com/wp-content/uploads/2020/06/Eeloo3-1024x859.jpg

https://www.kerbalspaceprogram.com/wp-content/uploads/2020/06/Eeloo1.jpg

Nice sleuthing but you have to admit that this obviously could point to one other planet (albeit not in the Kerbol System)

Spoiler

A planet named THE SPANISH INQUISITION!

(Because nobody expects...)

 

[K^2]

14 minutes ago, Kerbart said:

Then again, 128-bit math will give you 35 decimals, which, at a 1mm resolution gives you about one million billion light years (maybe half of that if you need signed integers). My pocket calculator uses them, so how hard can it be?

Are you ok with getting coffee between frames? Encryption algorithms routinely do math with 4096 bits of precision, but it's not fast. It's still basically instant if you just need a few numbers crunched, but once you're starting to run a simulation where you need to do this math millions times per frame, you run into problems.

But it's worse than that. Modern CPUs do double precision math just as well as single precision on the FPU. Yet games are entirely done in 32 bits. What gives? Well, nobody does math on FPU. I mean, some math is done on FPU, but almost none of the game animation, physics, AI, or FX run on the FPU, because we don't really work with scalar numbers. Almost everything we are interested in is either a 3-dimensional or a 4-dimensional vector. That's why modern CPUs have SIMD - Single Instruction Multiple Data. That comes in as either SSE or AVX instruction sets supported both by Intel and AMD processors. These were initially developed for encryption and encoding, but game developers jumped on them as soon as they became commonplace.

The SSE instructions pack 128 bits of data into a single register. That can be either 4 single precision or 2 double precision floating numbers. (Also, all kinds of levels of precision of packed integers, but we don't care about these as much.) SSE instructions are basically perfect for doing animation and physics in 3D. There's a dot product instruction built into the SSE4.1 that lets you do 3 and 4 dimensional dot products, and the square root operation on SSE registers runs about 10 times faster than computing it on FPU. It can also do 4 square roots at once! There are also handy shuffle operations that can be combined with component-wise add/multiply operations to do very fast cross products and even quaternion operations. Rotation using quaternions with a good SIMD algorithm can run in about 20 CPU cycles. So all good stuff.

And then there is AVX. AVX2 has support for floating point math with 256 bit registers. That means you can do math on 4 double precision numbers at once. And that should have been a major win for games, as it might sound like it lets you just port all of your SSE single precision code to AVX and run it in double precision. Except a few crucial operations are conspicuously absent. The problem is that an AVX register is just a pair of SSE registers, and crossing data between them just does not work well. That means no 3-dimensional dot product, no vector cross products, no quaternion math. This means that in practice, doing double precision math is several times slower than doing single precision math even on the most recent CPUs.

Unfortunately, while PCs have considerable overhead in terms of computational capability, the above is a death sentence to double-precision math on consoles. Modern consoles have underpowered CPUs. Next gen is a great improvement in absolute terms, but does no better in relative terms. It's still a machine with very beefy graphics and just an Ok CPU. Which means that majority of games that have a lot of skeletal animation, physics, or heavy AI load are going to be running right under the wire on CPU budget. And that means that using double precision math for physics is just not an option. Absolutely all of the physics on every modern game engine will run using SSE instructions. That means 4D single precision math is what the game has to be built around. And so when we need additional precision, we start building scene hierarchies, shifting origin of the simulation to be close to where the action is happening. If that means breaking up collision scene in multiple sub-scenes, we do that. And then 32 bits of precision is plenty. It's a bit of extra work, I would absolutely love to just shove double precision in there instead, but it works just as well in the end, and we get much, much better performance out of it.

There's also a factor that all the rendering done in 32 bits, but that's another rant story for another time.

[Incarnation of Chaos]

52 minutes ago, K^2 said:

Are you ok with getting coffee between frames? Encryption algorithms routinely do math with 4096 bits of precision, but it's not fast. It's still basically instant if you just need a few numbers crunched, but once you're starting to run a simulation where you need to do this math millions times per frame, you run into problems.

But it's worse than that. Modern CPUs do double precision math just as well as single precision on the FPU. Yet games are entirely done in 32 bits. What gives? Well, nobody does math on FPU. I mean, some math is done on FPU, but almost none of the game animation, physics, AI, or FX run on the FPU, because we don't really work with scalar numbers. Almost everything we are interested in is either a 3-dimensional or a 4-dimensional vector. That's why modern CPUs have SIMD - Single Instruction Multiple Data. That comes in as either SSE or AVX instruction sets supported both by Intel and AMD processors. These were initially developed for encryption and encoding, but game developers jumped on them as soon as they became commonplace.

The SSE instructions pack 128 bits of data into a single register. That can be either 4 single precision or 2 double precision floating numbers. (Also, all kinds of levels of precision of packed integers, but we don't care about these as much.) SSE instructions are basically perfect for doing animation and physics in 3D. There's a dot product instruction built into the SSE4.1 that lets you do 3 and 4 dimensional dot products, and the square root operation on SSE registers runs about 10 times faster than computing it on FPU. It can also do 4 square roots at once! There are also handy shuffle operations that can be combined with component-wise add/multiply operations to do very fast cross products and even quaternion operations. Rotation using quaternions with a good SIMD algorithm can run in about 20 CPU cycles. So all good stuff.

And then there is AVX. AVX2 has support for floating point math with 256 bit registers. That means you can do math on 4 double precision numbers at once. And that should have been a major win for games, as it might sound like it lets you just port all of your SSE single precision code to AVX and run it in double precision. Except a few crucial operations are conspicuously absent. The problem is that an AVX register is just a pair of SSE registers, and crossing data between them just does not work well. That means no 3-dimensional dot product, no vector cross products, no quaternion math. This means that in practice, doing double precision math is several times slower than doing single precision math even on the most recent CPUs.

Unfortunately, while PCs have considerable overhead in terms of computational capability, the above is a death sentence to double-precision math on consoles. Modern consoles have underpowered CPUs. Next gen is a great improvement in absolute terms, but does no better in relative terms. It's still a machine with very beefy graphics and just an Ok CPU. Which means that majority of games that have a lot of skeletal animation, physics, or heavy AI load are going to be running right under the wire on CPU budget. And that means that using double precision math for physics is just not an option. Absolutely all of the physics on every modern game engine will run using SSE instructions. That means 4D single precision math is what the game has to be built around. And so when we need additional precision, we start building scene hierarchies, shifting origin of the simulation to be close to where the action is happening. If that means breaking up collision scene in multiple sub-scenes, we do that. And then 32 bits of precision is plenty. It's a bit of extra work, I would absolutely love to just shove double precision in there instead, but it works just as well in the end, and we get much, much better performance out of it.

There's also a factor that all the rendering done in 32 bits, but that's another rant story for another time.

This is also without mentioning that Intel's CPU's will actually shift their power and clock targets significantly when engaging the AVX units, as they generate immense heat and require large amounts of power to remain stable. So dropping 1-2GHZ from the base clock isn't that uncommon; which means that unless your cooling solution is either a massive air cooler or liquid that not only can the clocks drop so badly that the AVX units actually compute slower than just performing the same operations on the FPU. That anything else that's not hitting AVX is also running much slower than it would otherwise, and generate additional heat while doing so.

And it wasn't until Ryzen that AMD had support for AVX2, and it's accomplished by "Fusing" two of the AVX units and ran at half speed. And the FX series only supports up to SSE4.2; with the previous Athlons not supporting SSE4. So on AMD's end the support is either slow or lacking for these modes entirely unless it's a modern AMD chip.

[K^2]

Yeah, Intel support of SIMD has been a little bit better, but consoles have been all AMD for an entire generation now and are heading for another generation of AMD chips, so that's sort of where the bar is. Some developers do create alternative paths to leverage higher capabilities on PCs that have them, but many don't bother, so console capabilities still define how we all develop games for better or worse.

[Misguided Kerbal]

Does nobody notice this?

lol

Edited June 13, 2020 by Misguided_Kerbal

[mattinoz]

8 hours ago, SOXBLOX said:

uuouu! But seriously, this is cool. 

Also, can anyone explain this Spatial Scene Graph in more detail? What is it doing, how will it effect gameplay?

Thx.

At a guess a fancy way of saying they'll store orbital information in a way that lets them calculate the position at any time (graph),  instead of updating the position every tick then writing to file every save. 

The active physics bubble can ask the scene graph for part of the graph, say only the objects bright enough to cause light in the scene, and keep track of those in memory. On the grounds a smaller number still need to be used to calculate gravity. Or solar power generation, etc....

At a guess only (he repeats) but lets them do multiple body physics and deal with floating point calculations in a fast manner. and use a unit smaller than a mm. Oh also seems to be the key to making multi-player work by well reducing information to the bear minimum data needed to sync. As in player only need to know the Scene Graph until they are close and if they aren't close enough to effect each other directly could be at different times in the graph by some degree.

Also might explain why they needed a new network engineer if the first one is this high up it the creative structure.

 

[RealKerbal3x]

Great to know that the development is still continuing despite the current shenanigans. I'm still very excited for the game and I can't wait to see what specific solution they have for multiplayer

[OOM]

This is me after the daytime brain strain in KSP 

lol

 

Edited June 13, 2020 by OOM

[KerikBalm]

La grange points, really?

This interests me