I don't like Unity (Split from "Blocker features in KSP2")

[NoMrBond]

If we drop the problems which come from Unity's accessibility (i.e. learner and/or beginner devs using the most accessible framework) then the only thing that's really left is the physics bottleneck, which wouldn't really be solved by another engine since the performance hindrances remain (calculations on related groups of bodies remain in a single thread)

Assuming Star Theory stays current with Unity versions, and moves up to Unity 2019.3 (or better) before any code-freeze leading up to release, we could (should) see an update to PhysX 4.x which should further help (beyond the massive refactoring) in addressing the physics bottleneck

 

 

Edited October 23, 2019 by NoMrBond

[Concodroid]

1 hour ago, ronson49 said:

And this is just PARTS,  there are people on the threads here talking about Voxel Surfaces, and Ray Tracing.   I mean that is far far out into the realms of fantasy land!

Nope. It isn't. It's graphical. We have problems with the computational part, the GPU isn't actually being used all that much. Also, what are your computer specs?

Edited October 23, 2019 by Concodroid

[mcwaffles2003]

1 hour ago, ronson49 said:

I will just say no for the sake of this thread since my knowledge is outdated however, I am an avid reader of say, https://jacksondunstan.com for example and I know him from a previous technology.  Always loved his dedication to his blog for all these years, and his psychopathic fixation on squeezing the last bit of performance out of any compiler he focuses on.   I wouldn't therefor say I am clueless and spouting nonsense with no basis but I am hardly accurate either with the nomenclature.  For example people are jumping on my "Unity is Java" comment shooting it down with pedantics, but the underlying concept is still true.   Your Momo code is managed code and just like anything with managed code,  DONT USE IT if performance is your goal.   It is that which causes the "intermittent jitter" seen in ALL unity games. 

Since performance is the definition of KSP,  meaning that,  if the Engine runs at 2fps with 1000 parts.... that destroys the game experience.   It means I have to design a ship with 500 parts..... to fudge Unity into running at 30fps....      

 

By using Unity again,  the same thing will happen.   The concept is there, it is epic, it is so good,  but alas,  by the time I have a mun base ready to explore the solar system,  I am at 3fps.   My game should not be ending here,  it should be just starting and my performance budget is zero.   We need 100 times the magnitude of part peformance, and everything else should come second to that.    We aren't going to get anything like that in Unity,  and you can't just "optimise it away" like everyone is saying either. 

 

And this is just PARTS,  there are people on the threads here talking about Voxel Surfaces, and Ray Tracing.   I mean that is far far out into the realms of fantasy land!

 

 

Why do you believe that high part count affecting performance is the fault of unity specifically? I think this is what is throwing everyone through a loop

[steve_v]

2 hours ago, ronson49 said:

Your Momo code is managed code and just like anything with managed code,  DONT USE IT if performance is your goal.   It is that which causes the "intermittent jitter" seen in ALL unity games. 

While garbage collection is indeed inherent to a managed runtime (and mono's GC stops everything while it runs), there are ways to minimise the impact. Hopefully Star Theory knows what they are doing.

Personally I agree that mono is a poor choice for performance sensitive applications, but the only alternatives I can think of are a limited scripting language for modding, or subjecting modders to old-school manual memory management - and all the difficult to pin down bugs that it will introduce.

 

1 hour ago, mcwaffles2003 said:

Game clock vs Real time Clock is at 1 second : 3 seconds for me actually, I'd consider that playable

Well that explians it then. IMO yellow clock is bad clock, and physics running at anything less than realtime != "fine".

[mcwaffles2003]

12 minutes ago, steve_v said:

While garbage collection is indeed inherent to a managed runtime (and mono's GC stops everything while it runs), there are ways to minimise the impact. Hopefully Star Theory knows what they are doing.

Personally I agree that mono is a poor choice for performance sensitive applications, but the only alternatives I can think of are a limited scripting language for modding, or subjecting modders to old-school manual memory management - and all the difficult to pin down bugs that it will introduce.

 

Well that explians it then. IMO yellow clock is bad clock, and physics running at anything less than realtime != "fine".

better than 1:6 at least :p

I agree though, real time is obviously the goal and I'd say even 2:3 would be fine. Honestly I'd just prefer less kraken events on large ships, to me thats the truest hindrance to building larger ships

A big fix toward the game would just be welding body parts together that make sense making a single rigid body, for instance; multiple stacks of fuel containers welded together, accessories like lights being welded to the body, multiple stacks of batteries, science modules being welded to the storage container they're in, etc...

Edited October 23, 2019 by mcwaffles2003

[shdwlrd]

1 hour ago, mcwaffles2003 said:

Game clock vs Real time Clock is at 1 second : 3 seconds for me actually, I'd consider that playable

That was really noticeable with my older AMD machine with low part counts. My Intels and Ryzen don't time lag like that until you start getting to about a thousand parts. The Ryzen (2700x) starts lagging before the Intels though. (6th and 7th gen i7s.) But yes, it was annoying, but the game wasn't completely unplayable.

Basically, the hardware you run can and will impact a game's performance.

More to the point, I've played several of the Unity games that were listed in the wiki link earlier in this thread. The only games I've encountered performance issues was KSP, Cities: Skyline, and BattleTech. (Ok, Universal Sandbox would start lagging out once you started colliding hundreds of objects together.) The rest were solid and ran great.

Any software pushed to and beyond its limits or the limits of your hardware will run like crap.

 

[runner78]

With Unity's C# Job system and Burst compiler you can also create high-performance code with Unity, without Mono as bottleneck. For prepare and scheduling Mono is fast enough.

And Unity has alo the IL2CPP build option, and create C++ code from the .NET IL code and the game no longer use Mono. But that is not modding friendly.

Here some benchmarks: https://github.com/nxrighthere/BurstBenchmarks

[mcwaffles2003]

So as I understand, rigid body physics supposedly cant be multi-threaded due to the fact that when a part is moved it affects all parts it's touching, so if two or more threads call to a specific part at the same time there's a chance that the data about that part will be updated differently among different threads causing a discrepancy over the state of that part post calculation, can someone confirm that or deny that for me?

If that isnt the case why cant it be made sure that threads never work on the same or neighboring parts at the same time? Since ships are built like trees without closed loops (with exception to a strut) then why cant new threads be formed at branch points?

[runner78]

56 minutes ago, mcwaffles2003 said:

If that isnt the case why cant it be made sure that threads never work on the same or neighboring parts at the same time? Since ships are built like trees without closed loops (with exception to a strut) then why cant new threads be formed at branch points?

Also a tree branch are joined to the main branch, if you separate them, then you have cause a strange unpredictable behavior. 

Unity has with they new DOTS approach also Havok as physic engine available. If currently in preview, and should be production ready at the beginning of 2020. But i don't think KSP2 using DOTS (maybe for simulation only).

[mcwaffles2003]

4 minutes ago, runner78 said:

Also a tree branch are joined to the main branch, if you separate them, then you have cause a strange unpredictable behavior. 

Unity has with they new DOTS approach also Havok as physic engine available. If currently in preview, and should be production ready at the beginning of 2020. But i don't think KSP2 using DOTS (maybe for simulation only).

do you think its possible in an update to incorporate something like this? or will we be back to the "its too deep into the code" which would require a KSP 3 rebuild?

[The Aziz]

9 hours ago, shdwlrd said:

 KSP, Cities: Skyline, and BattleTech. (Ok, Universal Sandbox 

And this is no surprise. I don't know BattleTech, but the rest of these games rely heavily on cpu. I do check that in task manager. KSP needs to determine how the ship acts in flight (so, physics) and all orbital calculations (more maths) at the same time. Universe sandbox works the same way, but probably even more complex and realistic. Again, cpu calculations. Cities Skylines works fine until you make the city really big, and suprise, it needs a lot of cpu power to keep the traffic, and all other simulations working. And while it uses only 10 gigs of RAM, almost all my 3.2GHz are in use when I'm playing.

I don't know, but to me it looks like unity is indeed a good base for games that need a lot of processing power to work.

Garbage collection is a memory thing, right? So while I agree that after a while it can clog up and a game restart is needed, it's not exactly the main requirement OR problem here.

[runner78]

 

10 minutes ago, mcwaffles2003 said:

do you think its possible in an update to incorporate something like this? or will we be back to the "its too deep into the code" which would require a KSP 3 rebuild?

The DOTS approach is different from the old, but is very fast. The whole game to change would be too expensive and not all Unity components supporting it yet. But you can create hybrid games, using both approaches a the same time.

[mcwaffles2003]

2 minutes ago, runner78 said:

The DOTS approach is different from the old, but is very fast. The whole game to change would be too expensive and not all Unity components supporting it yet. But you can create hybrid games, using both approaches a the same time.

 

watching this and a few other vids about DOTS. Presenter here at least sound encouraging, talking about incremental implementation

Edited October 24, 2019 by mcwaffles2003
typo

[runner78]

Some part of DOTS is already production ready (C# job system and Burst compiler), the ECS system should be production ready for Unity 2020.1. The next step is to update many Unity modules to DOTS.

If KSP2 uses PhysX and has make some complex changes/hacks switch to DOTS would be difficult.

A later update to DOTS would break all mods.

[mcwaffles2003]

Just now, runner78 said:

Some part of DOTS is already production ready (C# job system and Burst compiler), the ECS system should be production ready for Unity 2020.1. The next step is to update many Unity modules to DOTS.

If KSP2 uses PhysX and has make some complex changes/hacks switch to DOTS would be difficult.

A later update to DOTS would break all mods.

Mods be damned then, they'll rebuild, but a highly efficient foundation to the games core mechanics is what I think we all want most

[sturmhauke]

48 minutes ago, The Aziz said:

Garbage collection is a memory thing, right? So while I agree that after a while it can clog up and a game restart is needed, it's not exactly the main requirement OR problem here.

There are two ways for a program to free up memory it no longer needs - manual deallocation or automatic garbage collection. The garbage collector uses a bit of memory and CPU time on its own; practically speaking, languages that use a garbage collector also tend to run on a virtual machine rather than being compiled to run at a lower level, which also adds to the overhead.

Manual memory management can potentially be much leaner, but is also more prone to errors, sometimes nasty ones. And honestly I don't trust your average modder to do it properly.

[runner78]

19 minutes ago, sturmhauke said:

Manual memory management can potentially be much leaner, but is also more prone to errors, sometimes nasty ones. And honestly I don't trust your average modder to do it properly.

Unity has his own native collection like NativeArray and NativeList. This memory is managed by Unity native and has no garbage collection.

[Guest]

2 hours ago, sturmhauke said:

Manual memory management can potentially be much leaner, but is also more prone to errors, sometimes nasty ones. And honestly I don't trust your average modder to do it properly.

I would not want to use manual memory management except in areas where I really absolutely have to. It's not that it's hard because it's not; it's that you have to be really meticulous about it, and no matter how good you are, it's likely you'll forget something somewhere and leave a memory leak. And memory leaks are exactly the kind of thing your unit tests won't catch. It'll likely only be caught very late in the game, if you're unlucky only when you get into production, and at that point it can be really difficult to fix, depending on what the cause is.

The problem with automatic memory management is that you still have to understand how memory works. If you're careless with it you will end up churning memory way more than you ought to, which means the garbage collector works way more than it ought to. But that's not the garbage collector's fault, it's the programmer's for writing a program that puts it into overdrive.

Without ever having seen KSP's codebase, I strongly suspect that this is the problem with that infamous garbage collection stutter too. Not Unity, not garbage collection, but code that's structured in a way that doesn't use memory stably and efficiently. And if that's deep in the architecture, it really can't be fixed without refactoring that's so extensive that you might as well rewrite it.

[SolarAdmiral]

I think this deserves a moment of a appreciation of how complicated KSP is in many areas compared to most games.

 

- Gravity simulated based on distance from a mass in 3d space rather than a single variable directed always down. And transferring moving objects on trajectories accurately between SOIs. 

- 14  1/10 th scale planets and moons with surface topology all in a single instance or map. To be viewed in a overall map, landed on, and at every distance between.

- A solar system's worth of space to accurately position moving planets objects and ships in.

- Player built aircraft, spacecraft, and stations. With gravity, thrust, aerodynamics, and collisions modeled.

- 3 major different camera environments. Plus additional menus.

 

There aren't many games that do even one of these things. Let alone all of them. 

Most games built to look pretty and fancy with the latest graphics tech are first or third person games where you control a single camera perspective around a map maybe a few kilometers across that ends in a wall surrounded with fake scenery, skyboxes, and other visual trickery.

 

[sturmhauke]

7 hours ago, runner78 said:

Unity has his own native collection like NativeArray and NativeList. This memory is managed by Unity native and has no garbage collection.

Not exactly. Those are both subtypes of NativeContainer, and Unity has a garbage collector that runs in the background. When instantiating a NativeContainer, you have to specify the Allocator type, one of which (Persistent) tells the garbage collector to leave it alone until called or the application ends. So you can still be careless and request a bunch of memory and then forget to dump it later, but you at least have to think about it first.

https://docs.unity3d.com/Manual/JobSystemNativeContainer.html

Edited October 24, 2019 by sturmhauke

[ronson49]

1 hour ago, SolarAdmiral said:

Most games built to look pretty and fancy with the latest graphics tech are first or third person games where you control a single camera perspective around a map maybe a few kilometers across that ends in a wall surrounded with fake scenery, skyboxes, and other visual trickery.

Unity can't even do that well!!! 

[SolarAdmiral]

6 minutes ago, ronson49 said:

Unity can't even do that well!!! 

Plenty of games look great on Unity. But looking fantastic is a function of the art budget more than the engine. 

[Kerbart]

9 minutes ago, ronson49 said:

Unity can't even do that well!!! 

I don’t want to come over as argumentative, but I think that providing a few samples would bolster confidence in your statement. I haven’t seen any compelling argument that KSP’s perceived lack of performance is, in fact, due to Unity, and not due to inefficient code.

I can write exceptionally bad performing C++ code that uses, say, the Unreal engine, to “proof” that C++ and Unreal are exceptionally slow but that doesn’t proof anything. Looking at the development history of KSP it’s a lot more tempting to put the money on “not utilizing Unity the right way” than on “LoLz iT sUcKs BrO” as the reason it’s not as fast as we want it to be.

[shdwlrd]

18 minutes ago, ronson49 said:

Unity can't even do that well!!! 

Subnautica does a good job at looking good in a first person fashion.

[mcwaffles2003]

48 minutes ago, ronson49 said:

Unity can't even do that well!!! 

I love how you just dont bother reading anything people provide that differs from your opinion, it's not like a game like this wasnt already brought up... oh wait

On 10/20/2019 at 4:48 AM, mcwaffles2003 said:

https://en.wikipedia.org/wiki/List_of_Unity_games

Subnautica

It's 3-D, beautiful, runs well, has free building in a lego like manner similar to kerbal, and is built in unity

Unity may be a free engine available to everyone, so many amateurs may make sub par inefficient games using it but that doesnt mean in the correct hands it cant be used to make something great.

But please tell me that subnautica chugs or looks ugly to defend your point

Really good point though, your opinions seem very thoughtful and well informed. Good luck dude