Unity vs Graphics API - KSP2

[GoldForest]

I've seen a lot of people bashing unity, but unity is a great game engine. Some of the games made with it include Cuphead, Cities Skyline, and even Rick and Morty VR. 

I think they associate the poor performance with unity and not the graphics API. There is a difference. It's the graphics API that causes the poor performance. DX9 is old. Really old now. 2002 it came out and support dropped around 2007 iirc. 12 years. That's a long time. 

People are suggesting there will be the same performance or worse with KSP2 and I can't bring myself to believe that, not unless they dont upgrade from DX9, which I feel they have. If they are using DX11, DX12, or even DX11 with DX12 upgrades, performance will shoot up I would imagine nearly 4 to 10 times. The same could be said for AMD's Vulken API. 

I wish people would see that unity isn't a bad engine. It isn't the problem. If you want to see what Unity can do, YouTube the unity tech demo and see how powerful this little game engine is. 

KSP 1 can't get anymore performance not because of unity, but because of DX9.

KSP 2 can get higher performance with DX11, DX12, DX11+12 or Vulken. 

Sorry for the rant, but I felt the need to address this issue.

Any criticism or comments are fully welcome.

[Manwith Noname]

I'm sure someone with more time on their hands can give a more lengthy response but I have two points to make.

1) You can run KSP in DX11 and get a really minor performance boost. The API is less significant to KSP performance issues than you think.

2) Cities Skylines has terrible performance and runs in DX11.

Can Unity be used to make good games? Yes. however, there is a very common trend that complex Unity games run poorly.

[GoldForest]

12 minutes ago, Manwith Noname said:

I'm sure someone with more time on their hands can give a more lengthy response but I have two points to make.

1) You can run KSP in DX11 and get a really minor performance boost. The API is less significant to KSP performance issues than you think.

2) Cities Skylines has terrible performance and runs in DX11.

Can Unity be used to make good games? Yes. however, there is a very common trend that complex Unity games run poorly.

Yes, KSP can run in DX11, but it was made in DX9. That's why the increase in performance is minor.

As for Cities Skylines, I dont notice that much of a performance issue until the cities start to span nearly the whole map( all 25 to 36 squares.)

As for complex unity games running poorly, it comes down to optimization. 

If they make KSP 2 in unity with dx12, and optimize it, it would get far greater performance than unity with dx9.

[Manwith Noname]

Cities Skylines bogs down when the AI simulation becomes too much for your CPU to process within the render time for a frame. KSP bogs down when the physics simulation becomes too much for your CPU to process within the render time for a frame. These problems are not draw call related, which is where most performance increases have come through DirectX revisions. KSP 2 will likely suffer from the same problems unless they simplify how physics per part are calculated.

[GoldForest]

15 minutes ago, Manwith Noname said:

Cities Skylines bogs down when the AI simulation becomes too much for your CPU to process within the render time for a frame. KSP bogs down when the physics simulation becomes too much for your CPU to process within the render time for a frame. These problems are not draw call related, which is where most performance increases have come through DirectX revisions. KSP 2 will likely suffer from the same problems unless they simplify how physics per part are calculated.

If the problem is physics calculations, would it be beneficial to allow the GPU to use its built in physics renderer, like Nvidia PhysX? Or allow both CPU and GPU physical rendering in tandem?

[53miner53]

2 minutes ago, GoldForest said:

If the problem is physics calculations, would it be beneficial to allow the GPU to use its built in physics renderer, like Nvidia PhysX? Or allow both CPU and GPU physical rendering in tandem?

*has Intel integrated graphics*

*computer hides in corner fearing for its life*

Edited August 21, 2019 by 53miner53
Decided to be more specific

[Incarnation of Chaos]

24 minutes ago, GoldForest said:

If the problem is physics calculations, would it be beneficial to allow the GPU to use its built in physics renderer, like Nvidia PhysX? Or allow both CPU and GPU physical rendering in tandem?

The simple answer is these will almost always work better on CPU's.

The more complex answer is while threadsafe physics implmentations exist; these would be better used to exploit multicore CPU's because they would be almost universally supported. GPU Agnostic Physics is something i have no clue if it even exists; most stuff like this (Which mostly lies in the academic spaces) is written with CUDA or OpenGL. CUDA is only supported with Nividia GPU's; AMD GPU's often struggle with OpenGL unless careful attention to optimization is taken. So i seriously doubt GPU physics will be a thing for any game; and before you say "But muh Vulkan" much of the performance Vulkan gains is from being a hard break from OpenGL and lacking much of the backwards compatiblity and precision that OpenGl has.

I would love to see Multithreaded Physics; but that's because i know there's ways to accomplish it. GPU Physics is likely going to remain an extremely specialized solution that's talior made for a specific set of hardware and simulations for a very long time.

[GoldForest]

2 minutes ago, Incarnation of Chaos said:

The simple answer is these will almost always work better on CPU's.

The more complex answer is while threadsafe physics implmentations exist; these would be better used to exploit multicore CPU's because they would be almost universally supported. GPU Agnostic Physics is something i have no clue if it even exists; most stuff like this (Which mostly lies in the academic spaces) is written with CUDA or OpenGL. CUDA is only supported with Nividia GPU's; AMD GPU's often struggle with OpenGL unless careful attention to optimization is taken. So i seriously doubt GPU physics will be a thing for any game; and before you say "But muh Vulkan" much of the performance Vulkan gains is from being a hard break from OpenGL and lacking much of the backwards compatiblity and precision that OpenGl has.

I would love to see Multithreaded Physics; but that's because i know there's ways to accomplish it. GPU Physics is likely going to remain an extremely specialized solution that's talior made for a specific set of hardware and simulations for a very long time.

Hmmm, we'll just have to wait and see, but I imagine they will have done some backdoor trickery or fix to deal with high demand physics situations. I mean, they have an orion drive, which they show giving off an explosion every few seconds. Not only that, but the size of the parts and crafts they showed was immense. 

[NoMrBond]

If they're using a later version of the Unity engine (2018.3 or better) then they'll get the advantage of PhysX 3.4 which should be a decent upgrade

In one of the dev interviews at Gamescom it sounds like part of the KSP2 push has been restructuring and refactoring the entire codebase

The breaking of compatibility affords them the ability to really dig deep and fix/change what's needed without worrying about what it might do to peoples saves or other concerns

Edited August 21, 2019 by NoMrBond

[Nightside]

4 minutes ago, NoMrBond said:

without worrying about what it might do to peoples saves

I wish they weren’t so concerned with that. Really it just seems like an excuse to not address a big issue.

[The Aziz]

I'm just relieved that they don't do it in unreal engine. Epic would come and force them to be their another exclusive title (like they did with many games built on that engine)

[GoldForest]

8 minutes ago, The Aziz said:

I'm just relieved that they don't do it in unreal engine. Epic would come and force them to be their another exclusive title (like they did with many games built on that engine)

Epic doesn't force them to do anything. The publishers agreed to make their game exclusive because Epic gave them money. But please don't take about Epic exclusivity here, let's stay on topic please. 

Edited August 21, 2019 by GoldForest

[TBenz]

2 hours ago, Nightside said:

I wish they weren’t so concerned with that. Really it just seems like an excuse to not address a big issue.

It runs way deeper than that. The amount of rewriting required to fix some of the bugs in KSP 1 would amount to nearly creating an entirely new game. Which they ultimately decided to do, hence this whole KSP 2 thing. 

[Psycho_zs]

The main hurdle in KSP is physics. In two parts: poor performance of Unity's physics engine (or the way it was used in KSP 1) and soft body model not being the most appropriate choice for simulating rockets. They might fix or smooth over the first problem (it's one of their stated goals), but we have no idea yet of what (if anything) they are going to do with the second. That german interview featured pre-alpha footage of some extremely floppy rocket, same undampened springy noodle motion, it seems.

[GoldForest]

7 minutes ago, Psycho_zs said:

The main hurdle in KSP is physics. In two parts: poor performance of Unity's physics engine (or the way it was used in KSP 1) and soft body model not being the most appropriate choice for simulating rockets. They might fix or smooth over the first problem (it's one of their stated goals), but we have no idea yet of what (if anything) they are going to do with the second. That german interview featured pre-alpha footage of some extremely floppy rocket, same undampened springy noodle motion, it seems.

So Pre-0.90 (???) joint system redo? Great, hope Kerbal Joint Reinforcement gets updated for KSP 2 quickly if that's the case. 

Edited August 21, 2019 by GoldForest

[Radekpl]

You can now use Unity ECS for handling physics for all parts with easy.

Poor performance from KSP 1 is due to physisc handling is done with "heavy game object" which hold a lot of datas for physics handling and also functionality and rendering. If they split physics to ECS they can easilly run ships made from hundred thousand parts.

42 minutes ago, Psycho_zs said:

The main hurdle in KSP is physics. In two parts: poor performance of Unity's physics engine (or the way it was used in KSP 1) and soft body model not being the most appropriate choice for simulating rockets. They might fix or smooth over the first problem (it's one of their stated goals), but we have no idea yet of what (if anything) they are going to do with the second. That german interview featured pre-alpha footage of some extremely floppy rocket, same undampened springy noodle motion, it seems.

Floppy rocket (soft model) is not bug(poor choice for rocket building), it is feature

[Technical Ben]

4 hours ago, Nightside said:

I wish they weren’t so concerned with that. Really it just seems like an excuse to not address a big issue.

I highly doubt that modders will be unable to "port" existing saves. There are 2 options. Load up all craft/positions (use conversions if things move slightly) and port over existing parts/designs (if existing parts make it to KSP2).

Other option, port over positions, then ask the player to choose an existing KSP2 ship save/design to replace each craft in the KSP1 save. That way, you can "port" over the save. It's basically hyperedit automated.

 

PS, I'd love them to offload a lot of physics to the VAB. Once the craft is designed, "test" the ship design for a few seconds with a few bits of physics. See it's max G threshold, rotation/wobble etc. If the ship is fine at low G, flag that G limit, and *dont* run any physics sims on it until the craft exceeds that G (or rotation/etc). That way you only need to sim the craft when it's throttling, wobbling, moving, docking, etc. Currently the sim sims constantly, even if nothing is happening to the craft. This bogs the game down. See how fast it runs in timewarp for an example. Now, if it could figure out when/what parts to sim, you'd only hit "slow mode" when the ship crashes/breaks/explodes (even when rotating/maneuvering as above).

That way, you get cool slow mode explosions, and the CPU "lag" becomes a feature, not a limit. Then when the explosions finishes, everything goes back to silky smooth.

Edited August 21, 2019 by Technical Ben

[Incarnation of Chaos]

They've said numerous times that saves won't be fowards compatible; I wouldn't get your hopes up for any type of save transfer. 

[Teek]

Yeah, the physics calculations in KSP2 will be an interesting conundrum.  On one hand, we've already seen floppy rockets, which I'm not necessarily against.  I've seen arguments for making everything procedural or locking in parts, but to a certain extent the wobbliness in KSP is a part of its identity, and I'd hate to see it removed altogether.

That said, I'm not sure how that modeling system will work with KSP2's focus on larger scale builds, like that Daedalus rocket, or colonies and space stations.  Perhaps they will vary the physics modelling based on the location of the ship or the type of construction?  Or perhaps you can enable it as a part setting or some additional modification (possibly a later game unlock.)

[Clockwork13]

18 hours ago, GoldForest said:

I've seen a lot of people bashing unity, but unity is a great game engine.

Unity is usually a good game engine, but with large games (space and physics oriented games especially) like KSP, there's often technical limitations or weird unfixable physics bugs that appear (e.g. the Krakens).

Though on the other hand, it makes sense if they want to port KSP 2 to various platforms, which would be completely unfeasible if it were written from scratch without a proper game engine.

[Kerbart]

14 hours ago, TBenz said:

It runs way deeper than that. The amount of rewriting required to fix some of the bugs in KSP 1 would amount to nearly creating an entirely new game. Which they ultimately decided to do, hence this whole KSP 2 thing.

That is exactly the biggest issue; not the game engine or graphics interface. KSP in its current form is a software experiment that turned into a game, changing implementation direction during its development history multiple times.

Hindsight is 20/20 and the game, without doubt, contains many architectural choices where everyone in Squad agrees that had they known they’d end up with 1.7 in its current form, they would never  have made decision x or y.

Even if KSP2 would use the same technology base as KSP1, it would be many times faster and more  stable, because it would have an architecture designed to deliver exactly that, and not some Frankenware with dozens of extensions bolted on top of each other.

[cantab]

KSP has performance problems running on OpenGL on Linux too. There are other games on Linux, some using Unity, that don't have issues like KSP has. In particular the garbage-collection stutter has everything to do with Unity's outdated version of Mono, and KSP's code running on top of that, and little if anything to do with DirectX.

I've seen nothing to make me think any other general-purpose engine would be better than Unity for KSP2. I don't know any games in other engines that come close to KSP's scale and range of speeds. I've long advocated a custom or special-purpose engine, perhaps Space Engine, but Star Theory have decided not to change.

For what it's worth, Simple Rockets 2 also uses Unity.

[NoMrBond]

37 minutes ago, cantab said:

... the garbage-collection stutter has everything to do with Unity's outdated version of Mono...

Hopefully they're using at least Unity 2018.3 for the undated mono, and even more hopefully (but less likely since it only came out in April) Unity 2019.1 which has the improved incremental GC

[stargazer1235]

1 hour ago, cantab said:

I've seen nothing to make me think any other general-purpose engine would be better than Unity for KSP2. I don't know any games in other engines that come close to KSP's scale and range of speeds. I've long advocated a custom or special-purpose engine, perhaps Space Engine, but Star Theory have decided not to change.

For what it's worth, Simple Rockets 2 also uses Unity.

My thoughts exactly, I can't really think of any other game engine that is purposed built to handle something like KSP. As you said maybe Space Engine but that would have to be heavily modified to allow something like KSP to operate within it and I presume that devs have a certain expertise in using certain engins. While a purpose built would be nice, I presume that takes years of R&D that a small team, like Squard or Star Theory probably couldn't do. Additionally the costs would need to be recuperated somehow, presumably by lincencing then engine to other devs, and unfortuantly there isn't much of a market for highly specific space simulations at the moment.