I just heard of KSP 2. Are they officially using Unity?

[ezaroo]

4 hours ago, klgraham1013 said:

It depends if you're after photorealism or the stylized look Subnautica was actually going for.  Personally, I think Subnautica was beautiful and would have no problem if KSP also choose a more semi real approach.

Yeah graphics today is about design choice - they can choose photorealism or a stylised approach and both are valid. Would a photorealistic world look good with Karbals? Probably not, you probably have to stylise a bit. 

Games that choose to go down the more cartoon route often do it for their own reasons rather than because they have to.

I imagine KSP2 will be in between, more real looking than what we have currently but you aren’t going to think you’re looking at a real planet. Which is largely what we saw with the cinematic trailer, sharper and more real than KSP1, not quite what other games can produce. 

But it’s a design choice rather than a limitation.

[ShawnPhillips]

17 hours ago, horace said:

it should have dxr

Unity is getting Raytracing and RTX support later this year, so DXR could possibly be implemented to KSP2 at some point.

[wumpus]

There is more to Unity than the graphics engine.  KSP used the Unity physics engine as well, and this ultimately lead to the Kraken and the "floating origin" fix (something HarvestR liked so much he named his new studio after it).  Unless Unity can be convinced/compiled to run the physics engine in double mode (and eat the roughly 50% speed hit), the developers will be forced make similar adjustments over and over (not to mention that they need a completely different way to construct large crafts and constructable buildings [which may already exist]).

For those wondering, 16 bit floating point should be enough for most graphic shading.  I think AMD's new RNA does some of this.  Doing the same for geometry work *should* work as well,  but probably requires too much optimization work for too little gain (and those last few bugs look horrible and would be hard to fix).

32 bit floating point is overkill for just about any game (KSP being and odd example).  Calculating with 32 bits (24 bits of effective mantissa) is overkill when you only use at most 10 bits (maybe 12 bits in horizontal resolution).

64 bits are needed when you need to use previously computed values for the next calculation and so on and so on.  Anyone who learned to calculate "significant figures" via pencil and paper or calculator will get a sharp surprise when they learn how well numerical methods work when discarding "non-significant" precision in the midst of calculation (as far as I know, physically measuring to 32 bit precision is impossible in all but the most contrived experiments).  I've tried to do a 32k point FFT in single point and the audio was worse than 8 bit resolution, so accumulating the errors of 32k (yes, each point only did about 15 multiply adds, but they spread the errors around similar to the formal definition of the fourier transform) swamped the signal in the rounding errors.

Scott Manley's take (I didn't watch it again, and think it is almost entirely on address space although he probably mentions that "all scientific calculation *must* be done in 64 bit [or better]).
https://www.youtube.com/watch?v=TSaNhyzfNFk

 

On 9/18/2019 at 9:57 AM, ShawnPhillips said:

Unity is getting Raytracing and RTX support later this year, so DXR could possibly be implemented to KSP2 at some point.

This makes a lot more sense for RTX than typical "AAA" engines.  Just look at what it did to Quake 2 and expect garage-level developers (like Squad or even less funded) to churn out nearly perfect lighting like the latest engine without the huge teams needed to make a "2019 engine" work.

[runner78]

• 16 bit float or the "half" type: where accurate calculations are not necessary and speed is more important (but depends on the CPU or GPU). Often used in deep learning.
• 32 bit float or the "single"/"float" type: mostly used in games and most graphics Cards can do that best. With positioning, the problems starts with 10 KM from origin (10000 units). Eeloo Apoapsis 1135497132 KM (1135497132200 units)
• 64 bit float or the "double" type: for accurate calculations and biger numbers, normal consumer GPU's are bad with doubles, newer used for rendering.
• 128+ bit floats: some GPU/GPU using larger floats for intermediate values, but mostly used only in science.

Unity HDRP use camera centered rendering, that means an the GPU the camera is always the origin, but that not change the scene/physics origin.

Unity has also an new math library which has double vectors, and supported by the Burst compiler for job, i seen a NBody brenchmark, Bust are 140% faster then normal mono, and 60% faster then C++;

[magnemoe]

3 hours ago, runner78 said:

• 16 bit float or the "half" type: where accurate calculations are not necessary and speed is more important (but depends on the CPU or GPU). Often used in deep learning.
• 32 bit float or the "single"/"float" type: mostly used in games and most graphics Cards can do that best. With positioning, the problems starts with 10 KM from origin (10000 units). Eeloo Apoapsis 1135497132 KM (1135497132200 units)
• 64 bit float or the "double" type: for accurate calculations and biger numbers, normal consumer GPU's are bad with doubles, newer used for rendering.
• 128+ bit floats: some GPU/GPU using larger floats for intermediate values, but mostly used only in science.

Unity HDRP use camera centered rendering, that means an the GPU the camera is always the origin, but that not change the scene/physics origin.

Unity has also an new math library which has double vectors, and supported by the Burst compiler for job, i seen a NBody brenchmark, Bust are 140% faster then normal mono, and 60% faster then C++;

Make me wonder a bit about how modern processors works, the address space is 64 bit but the buss is 40 something. It can be expended if needed. 
internally you use 64 bit anyway so in an 10K core supercomputer where each of cores has an terabyte of ram its not an issue. 
Windows has some constrains simply so you don't use windows home for you server, hint its no issue for an file server in an small office

However does 16 bit floating point give any benefit outside of reduced storage space in an CPU? 
I guess the floating point unit on an modern APU still uses 32 bit? integer one is 64 as it need to work addressees and it help push data but 64 bit floating point is niche. 

Now the sad part is that you want 128 bit floats to fight butterflies. Yes the butterfly effect was because an 1/1000 degree difference. Outdoor thermometers used for logging is not 1/100 degree.

[Incarnation of Chaos]

4 hours ago, magnemoe said:

Make me wonder a bit about how modern processors works, the address space is 64 bit but the buss is 40 something. It can be expended if needed. 
internally you use 64 bit anyway so in an 10K core supercomputer where each of cores has an terabyte of ram its not an issue. 
Windows has some constrains simply so you don't use windows home for you server, hint its no issue for an file server in an small office

However does 16 bit floating point give any benefit outside of reduced storage space in an CPU? 
I guess the floating point unit on an modern APU still uses 32 bit? integer one is 64 as it need to work addressees and it help push data but 64 bit floating point is niche. 

Now the sad part is that you want 128 bit floats to fight butterflies. Yes the butterfly effect was because an 1/1000 degree difference. Outdoor thermometers used for logging is not 1/100 degree.

16 bit means you can basically split the 32 bit compute units and double the power of the GPU; scaling isn't perfect IRL but it still has decent gains. Also the issue with anything beyond 128bit instructions is most consumer chips don't support them or the support is poor; Ryzen 1 and 2 only perform them at half rate for instance. 

All of this is idle chatter regardless though; physics is going to be on the CPU and therefore for maximum support will use the lowest common denominator that they know of (likely 32bit instructions) 

[Demonreaper]

Unity is a really good engine, that is continuously improving. It is has its problems like all engines do, however if there is problem with game then it most likely due to the programming (the ability of the developers), and has nothing do with the engine. 

Here are some more games made with unity, but there are heaps made with unity but you probably don't realise (Haven't played these, but didn't realise they were made in unity).

- Beat Saber, osiris: new dawn,  homeworld: deserts of kharak,  stranded deep, victory at sea, the forest, rust, .

[GoldForest]

55 minutes ago, Incarnation of Chaos said:

16 bit means you can basically split the 32 bit compute units and double the power of the GPU; scaling isn't perfect IRL but it still has decent gains. Also the issue with anything beyond 128bit instructions is most consumer chips don't support them or the support is poor; Ryzen 1 and 2 only perform them at half rate for instance. 

All of this is idle chatter regardless though; physics is going to be on the CPU and therefore for maximum support will use the lowest common denominator that they know of (likely 32bit instructions) 

I wonder how well a CNT CPU/GPU or a Optical CPU/GPU would handle physics since they both supposedly have far better performance than transistor-based CPUs/GPUs

[Incarnation of Chaos]

1 hour ago, GoldForest said:

I wonder how well a CNT CPU/GPU or a Optical CPU/GPU would handle physics since they both supposedly have far better performance than transistor-based CPUs/GPUs

CNT? Likely pretty well since you could clock that thing sky high; optical i'm not sure of since it gives you better transistor density but not directly clockspeed gains.

[GoldForest]

8 minutes ago, Incarnation of Chaos said:

CNT? Likely pretty well since you could clock that thing sky high; optical i'm not sure of since it gives you better transistor density but not directly clockspeed gains.

Carbon NanoTubes. And Optical has no transistors, everything is light based, so the only clock speed limitation is the light itself. So you need higher clock speed? Shorter fiber optic cable. You need slower clock speed? Longer fiber optic cable. Or you could send the light through water. Water slows down light drastically.

[magnemoe]

3 hours ago, Incarnation of Chaos said:

16 bit means you can basically split the 32 bit compute units and double the power of the GPU; scaling isn't perfect IRL but it still has decent gains. Also the issue with anything beyond 128bit instructions is most consumer chips don't support them or the support is poor; Ryzen 1 and 2 only perform them at half rate for instance. 

All of this is idle chatter regardless though; physics is going to be on the CPU and therefore for maximum support will use the lowest common denominator that they know of (likely 32bit instructions) 

Good point, did not knew you could feed multiple floats trough an pipeline. 
And yes they will use the cpu alu anyway. 

Also the local frame of reference makes loads of sense in KSP, KSP does not have an huge map like GTA or WOW.
You are on an space station in orbit around an moon who orbits an planet who again orbit an star. And yes the station is also rotating. 
However the only force on the pieces is the station rotating and all move in the orbit around the moon, you can ignore that the moon and planet moves unless you want to travel out of the moon or planet soi. Trying to calculate everything in reference to the sun would be insane.

And all games who try to make the world feel alive does stuff in the background. Take the Khajiit caravans in Skyrim. They move between cities and you can run into them along the road. 
In one quest you have to contact one Khajiit and quest marker is moving around. 
However they are just an location who is updated until you come close enough and now they are in an fight because you getting close also spawned some bandits.
 

[Incarnation of Chaos]

2 hours ago, GoldForest said:

Carbon NanoTubes. And Optical has no transistors, everything is light based, so the only clock speed limitation is the light itself. So you need higher clock speed? Shorter fiber optic cable. You need slower clock speed? Longer fiber optic cable. Or you could send the light through water. Water slows down light drastically.

Wrong; magic isn't producing light it's some sort of device. So your switching speed will be limited by whatever is producing the light and however fast you can switch it+the properties of whatever it's transmitting thru.

Also i knew you meant Carbon NanoTubes; for some reason i decided to append the question mark as if you had caught me by surprise and i was briefly pondering the answer. Of course you can't read minds so you had no idea that was the intent; i apologize.

1 hour ago, magnemoe said:

Good point, did not knew you could feed multiple floats trough an pipeline. 
And yes they will use the cpu alu anyway. 

Also the local frame of reference makes loads of sense in KSP, KSP does not have an huge map like GTA or WOW.
You are on an space station in orbit around an moon who orbits an planet who again orbit an star. And yes the station is also rotating. 
However the only force on the pieces is the station rotating and all move in the orbit around the moon, you can ignore that the moon and planet moves unless you want to travel out of the moon or planet soi. Trying to calculate everything in reference to the sun would be insane.

And all games who try to make the world feel alive does stuff in the background. Take the Khajiit caravans in Skyrim. They move between cities and you can run into them along the road. 
In one quest you have to contact one Khajiit and quest marker is moving around. 
However they are just an location who is updated until you come close enough and now they are in an fight because you getting close also spawned some bandits.
 

As far as i was aware; the SOI system KSP1 and 2 are/will be using is a form of what you're talking about. When you enter kerbins SOI the only calculations done are for objects within the kerbin system; which is further constrained to a specific distance around the active vessel. Everything else is treated as "On rails" and not actively calculated; planets/moons are also always treated as "On rails" and cannot be affected by any actions in game (Shame we can't de-orbit gilly because of this)

As for doing things in the background; those are always just pre-scripted paths. Crack open the CK and you'll quickly see that all of the cool stuff you see is just a pre-made path the character(s) follow with some logic (Like if i'm at a chair, sit etc.) so nothing needs to be calculated except AI; which isn't as hard to do since each AI can be dumped on another thread.

[GoldForest]

6 minutes ago, Incarnation of Chaos said:

Wrong; magic isn't producing light it's some sort of device. So your switching speed will be limited by whatever is producing the light and however fast you can switch it+the properties of whatever it's transmitting thru.

Also i knew you meant Carbon NanoTubes; for some reason i decided to append the question mark as if you had caught me by surprise and i was briefly pondering the answer. Of course you can't read minds so you had no idea that was the intent; i apologize.

Well, of course the light source is also going to be a limiting factor, but a laser light turns on almost instantly when provided with power, so it's negilable I would imagine. The real bottleneck would be the transfer material. 

Ah, yeah, the question mark threw me for a loop. 

[Incarnation of Chaos]

1 minute ago, GoldForest said:

Well, of course the light source is also going to be a limiting factor, but a laser light turns on almost instantly when provided with power, so it's negilable I would imagine. The real bottleneck would be the transfer material. 

Ah, yeah, the question mark threw me for a loop. 

My prediction for what it's worth is that CNT chips will end up holding an advantage in clockspeed initally; but Laser Transistors will win out because not only do they have a density advantage (Apperently) but even more important since they use light instead of an electrical potential to switch they don't have the same issues with electromigration, ablation and others that Si and CNT transistors would (CNT wouldn't likely have migration issues, ablation and the low voltages needed to run them would be the primary ones)

[Guest]

CNTs are coming, I'm pretty sure, but we're a looong way from practical optical CPUs. It's not even clear they'll ever be competitive with electronic ones, there remain fundamental problems to solve.

[GoldForest]

16 hours ago, Brikoleur said:

CNTs are coming, I'm pretty sure, but we're a looong way from practical optical CPUs. It's not even clear they'll ever be competitive with electronic ones, there remain fundamental problems to solve.

This is true, but optical computing is still super young. Heck, I don't think there's been any hardware made, I think it's all just on paper stuff. 

Edited September 22, 2019 by GoldForest

[Talavar]

Realistically, building from the ground up in a C language will always destroy using a prebuilt engine, because it is tailored exactly to the game, but then you have to take into consideration the amount of time lost simply by building it from the ground up. While I'm not a complete "fan" of Unity, it has had it's moments when placed in the right hands. Unity has recently had some serious changes and major optimizations. All we can do at this point is hope that the team uses them to their fullest extent in the end. I'm optimistic, but you never know.. Anyway, all of us arguing, and trying to analyze it from the outside will really accomplish nothing except grumpy coffee mornings, and peacocked feathers. No matter what any of us think, or expect, we have only one option. That is "wait and see what they produce." So lets just wish them luck and, if it's good, fork over some cash for it.. lol

Edited September 21, 2019 by Talavar

[runner78]

5 hours ago, Talavar said:

Realistically, building from the ground up in a C language will always destroy using a prebuilt engine

Not always, Burst using LLVM/Clang to create aggressively optimized machine code from the IL code, in some cases it can be better optimized, as would be possible with normal C/C++ compiler.

 

[Talavar]

3 hours ago, runner78 said:

Not always, Burst using LLVM/Clang to create aggressively optimized machine code from the IL code, in some cases it can be better optimized, as would be possible with normal C/C++ compiler.

 

Honestly, It's been a long time since I've programmed anything, so my knowledge at this point compared to yours is probably classified as prehistoric.. That being said, I'll take your word for it. lol

[Incarnation of Chaos]

15 hours ago, GoldForest said:

This is true, but it's still super young. Heck, I don't think there's been any hardware made, I think it's all just on paper stuff. 

CNTs in general are barely off paper; we're a long way from industrial scale production of them.

[GoldForest]

46 minutes ago, Incarnation of Chaos said:

CNTs in general are barely off paper; we're a long way from industrial scale production of them.

I meant optical computing. 

[Incarnation of Chaos]

2 hours ago, GoldForest said:

I meant optical computing. 

tbh we'll likely have CNT CPU's well before optical; it's far easier to adapt a known process to a new material (Which would be the case for CNT CPUs). than it is to develop entirely new processes for entirely new materials (optical).

I'm willing to be surprised as always though.

[GoldForest]

57 minutes ago, Incarnation of Chaos said:

tbh we'll likely have CNT CPU's well before optical; it's far easier to adapt a known process to a new material (Which would be the case for CNT CPUs). than it is to develop entirely new processes for entirely new materials (optical).

I'm willing to be surprised as always though.

Well, with how slow it is to make CNTs I wouldn't be surprised if optical hardware started making it's day-view soon. I mean, we have all the technology right now to make it, not much more special hardware would be needed imo. 

[Incarnation of Chaos]

53 minutes ago, GoldForest said:

Well, with how slow it is to make CNTs I wouldn't be surprised if optical hardware started making it's day-view soon. I mean, we have all the technology right now to make it, not much more special hardware would be needed imo. 

Packaging and compatiblity with existing software/hardware will be the biggest issues.

[Jimbodiah]

On 9/14/2019 at 11:27 PM, linuxgurugamer said:

That would be amazing, since the developers do not yet know the bottlenecks.

The devs don't know the current bottlenecks in KSP1, which is why we need modders, so they are just implementing them into KSP2 and calling them features.

KSP2 will be stillborn.