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

[linuxgurugamer]

6 hours ago, Thygrrr said:

- existing mods can quickly port their assets, animations and materials to KSP2. I cannot stress enough how important this is! It practically seeds the KSP2 mod pool to ~30-50% the size of KSP1s pool within mere weeks of the release.

 

6 hours ago, Thygrrr said:

- same goes for UI layouts, textures, scenes, etc, even though the new game will also be moddable via Lua, which will probably do away with Module Manager and allow for much more intelligent "parts" without having to ship DLLs that are compiled against a specific version of the game

 

Mods will not be portable between the systems, and will not be possible to port a mod over.  KSP-2 is a totally new game, and Star Theory has stated that mods will not be possible to port over.

 

[Thygrrr]

38 minutes ago, linuxgurugamer said:

 

 

Mods will not be portable between the systems, and will not be possible to port a mod over.  KSP-2 is a totally new game, and Star Theory has stated that mods will not be possible to port over.

 

I am talkin about assets, sounds, models, textures. The stuff that REALLY takes long to get right in a quality mod.

They are the same between engines. Code will need a near-full rewrite for sure, as will all part definitions because the vessel system will be a new one and Module Manager will likely be superseded by the Lua scripting system.

Edited November 7, 2019 by Thygrrr

[linuxgurugamer]

1 hour ago, Thygrrr said:

I am talkin about assets, sounds, models, textures. The stuff that REALLY takes long to get right in a quality mod.

They are the same between engines. Code will need a near-full rewrite for sure, as will all part definitions because the vessel system will be a new one and Module Manager will likely be superseded by the Lua scripting system.

Not all mods are parts, models, etc.  For those mods which have a significant amount of code (probably more than 50%) will require a full rewrite

[sturmhauke]

Assets aren't necessarily portable either. They might need to be tweaked, converted to different formats, or redone altogether.

[shdwlrd]

1 hour ago, sturmhauke said:

Assets aren't necessarily portable either. They might need to be tweaked, converted to different formats, or redone altogether.

I think the point Thygrrr is trying to make is it's far less work to tweak a finished 3d model than having to redo it from scratch. The only headache will be redoing the config files for the parts. 

[Thygrrr]

Thanks, yes that's what I meant! And porting doesn't just mean copy paste run.

 

It means copy paste adapt run, versus design create iterate run. Something to adapt would be the materials for a model, but those are just a few texture references and a shader reference. The model itself already has all the UVs unwrapped so all you need to touch about a model that was already working in unity 2019/KSP 1.8 is probably the import settings regarding scale and pick the appropriate materials for the render pipeline.

Edited November 8, 2019 by Thygrrr

[sturmhauke]

This is the sort of thing I was talking about, and it's not even KSP2 yet. Assets aren't just 3D models, they're all the graphics, sounds, animations, etc. In this case it's part texture files, and they need to be converted to a different file format for 1.8.

[ronson49]

 

When they said "Next Gen Tech",  it certainly wasn't about the technology choice (Unity). lol

 

 

Almost all of the footage, including the first seconds of the video, has the "Unity Look"™.   The stuttery lagging renderer dropping frames for distant objects.   

 

This basically tells you all you need to know about how KSP2 is going to run,  it is going to be very similar to KSP1, maybe a 30% part count improvement (skeptical) and at that point, they can add 1000% more scale to the concept, but all of it is going to come out of part count and that part count is the the life blood of the game being fun.  13fps approaching my space base? No thanks, it kills the game and this video does nothing to show me that the bar has been raised.  

[.50calBMG]

Does the word pre-alpha mean anything to you? I remember a time when DCS World was a stuttery mess that looked as bad if not worse than ksp 1 in beta, and that was an engine specifically designed for  it. Now, DCS is arguably the best looking flight sim you can play, just because they had time to work on it. I have serious doubts that KSP 2 at release will look like it does in the pre-alpha gameplay.

[Incarnation of Chaos]

17 hours ago, ronson49 said:

 

When they said "Next Gen Tech",  it certainly wasn't about the technology choice (Unity). lol

 

 

Almost all of the footage, including the first seconds of the video, has the "Unity Look"™.   The stuttery lagging renderer dropping frames for distant objects.   

 

This basically tells you all you need to know about how KSP2 is going to run,  it is going to be very similar to KSP1, maybe a 30% part count improvement (skeptical) and at that point, they can add 1000% more scale to the concept, but all of it is going to come out of part count and that part count is the the life blood of the game being fun.  13fps approaching my space base? No thanks, it kills the game and this video does nothing to show me that the bar has been raised.  

It's pre-alpha, and the game is likely delayed by at least a couple months. 

[snip]

If it's so horrible that you won't play then it would seem that there's a niche in the market for you to fill! All you need is to write a entire engine from scratch, then model the assets, texture them, implement them in said engine and debug them. It's so easy i don't know why I'm not playing this hypothetical  game right now!

Oh wait; that's actually a significant amount of work. See ya on KSP2 fourms whenever it comes out then; because it's basically the only option for ya. Especially if you're that hungry for part count.

 

Edited February 24, 2020 by Snark
Redacted by moderator

[ronson49]

 

 

I had been quiet just because there was nothing to see.  As you know, I have a problem with Unity being used for a game of this scope which was my original point.   Many people told me that "Next Unity is out of this world"  "They will escape physics from the CPU loop and performance is outstanding".   

 

Doesn't seem to be the case, and I was expecting the "oh but its pre alpha" but that is pretty vague.  We can assume that as a studio greenlit for a sequel,  there is absolutely no way that the physics engine wasn't at the very heart of everything.  The "foundation stone",  and there is absolutely no way that the physics engine, is anything other than a first class citizen.  You can't make anything else before you have your physics model dialed in and therefor at pre-alpha that should be done.  The next year of the game is going to be developed assuming that is in place to make time for all of the other stuff which actually is the "game purpose".   The Pre Alpha with just physics engine and some hit boxes should be like 60+fps and buttery smooth. 

 

I mean you just can't argue that "no the physics are just a side job and it gets done as it goes along". 

 

What you see there is what you are going to get.   You can all see the "Unity Look™"   [snip]   The Unity Look™  is here and on that basis I stand by everything I have said about it being a primitive choice to realize this games potential. 

Edited February 24, 2020 by Snark
Redacted by moderator

[steve_v]

1 minute ago, ronson49 said:

They will escape physics from the CPU loop

That has nothing to do with unity, and everything to with the available underlying physics implementations.
As of now, there's nothing that can do connected-rigidbody trees on anything but the CPU, and almost entirely on one thread. That goes for any game engine.

If you want to suggest another game engine, I await your nomination and reasoning. If you're suggesting some bespoke physics engine, kindly math up or shut up.

[Dirkidirk]

Have you ever heard of universe sandbox 2, or Cities skylines?

Spoiler

No regrets

 

Edited February 24, 2020 by Dirkidirk

[ronson49]

11 minutes ago, Dirkidirk said:

Have you ever heard of universe sandbox 2, or Cities skylines?

  Reveal hidden contents

No regrets

 

Yes, one is spheres which I presume is the most performant model as it is just a point with radius.  It has none of the complexity of connecting parts into compounds which is instantly a performance bottleneck.   Cities Skyline has the Unity Look™ as soon as you build half a map.  

[Snark]

A lot of content has been removed from this thread, due to various rule-violating posts from people who should know better.

C'mon, guys, you know better than this.  We're all familiar with how things are done, here in the KSP forums, but perhaps a refresher is in order:

1. Address the post, not the poster.  Personal remarks are never called for.  If you find yourself making a comment about the person themselves, rather than simply addressing the points that they make, then that's either a sign that you're losing the argument, or that you need to take a step back until you cool down, or both.  If you find yourself using the word "you" a lot... that's a danger sign.  If you're talking about other posters in the third person, that's also a danger sign.  If you're actually name-calling, then that's a red flag that you're way over the line.  Just don't go there.  Either address what the person said-- i.e. the substance of their argument-- or, if you think that's unhelpful, then just stroll on by.
2. Don't tell other people what to do or what not to do.  You're not a moderator, it's not your place.  If you think someone is behaving so egregiously that they're actually violating the forum rules, then by all means file a report and the moderator team will have a look.  Otherwise, it's not your place to issue orders.
3. Don't publicly call for moderator action.  It's against the rules.  If you think the moderators need to step in, then file a report and we'll have a look-- but don't publicly request action, and don't publicly say that you have filed (or are going to file) a report.  That's called "backseat moderating" and is not allowed.

And, of course, the most important principle of all-- though not an actual "rule" written down-- is, relax.  Remember that opinions differ.  Different people like different things.  Different people believe different things.  Someone else likes or believes something that's very different from what you do-- and they're just as passionately attached to their opinions as you are to yours.  The existence of someone who differs from you is not a threat to you.  So if you feel like engaging in lively civil debate, by all means go to it, and good luck!

But if you're getting overwrought because you can't change someone else's mind, then it's probably best to take a step back and perhaps go elsewhere.  If you're not enjoying the conversation, then there's no point in continuing in it.

We  now return you to the thread already in progress.  Please play nice, folks.  Thank you for your understanding.

[Snark]

More content has been hidden, due to being off topic.

Folks, please try to stick to the topic. Arguing is fine. Arguing about arguing is not. Joking about arguing about arguing is off topic and unhelpful.  And please note that if you respond to something that gets removed, then your response will end up getting removed, too-- so please don't engage with off-topic posts, either.

Thank you for your understanding.

[έķ νίĻĻάίή]

On 2/24/2020 at 11:40 AM, ronson49 said:

Unity Look™

The Unity Look™? Never heard of that.

[Starman4308]

The primary limiting factor in how KSP looks is the art assets, and that suffers from the same problem that has plagued KSP for a long time: bandages over bandages over bandages over placeholders created by people with no expertise in game development. From what I've seen, I'm inclined to believe that Unity games can look good with talented artists at the helm, and if KSP 2 doesn't look that great, it's likely because their budget didn't stretch to hiring lots of excellent artists.

That's been a substantial divide between indie and AAA for a while now: while indie games tend to have more freedom to be creative, AAA studios have all the budget to hire legions of top-tier artists and the graphics programmers to bring their work to the screen with minimal GPU effort. A low-budget game has to get by on creativity, because you're never going to out-polish Call of Duty 5770912: Incrementally Prettier Explosions.

The primary limiting factor in how KSP performs is the rigid-body physics engine. The best publicly available rigid-body physics engine is likely tucked away in some scientific or engineering package, and certainly not in a game engine. While I still haven't gotten confirmation, I'm given to suspect it's an O(n^2) problem with current approaches, which means it's always going to be a monster. Even ignoring the fact that rigid-body physics is hard to parallelize, O(n^2) is a bad regime to be in; quadrupling your performance only doubles the number of parts you can add for the same calculation speed.

What KSP 2 is likely doing is sidestepping the problem with either static or dynamic parts welding, treating assemblages of parts as a single "part" in the rigid-body physics engine. If the total number of rigid-body elements is kept under ~100, even a sloppy, inefficient rigid-body physics engine is likely able to keep pace. Now, I suspect Unity's rigid-body physics engine is reasonably good, but this goes to show one thing.

Working around the limitations of an engine can sometimes be far more productive than trying to optimize or switch engines. KSP 1 hasn't done that, likely out of a combination of difficulty (see bandages on top of bandages leading to fragile spaghetti code) and the probability of breaking savegames. KSP 2 has the opportunity and funding to take a step back and say "we're going to do this right, and that means dealing with this rigid-body physics mess the right way from the start".

Switching game engines won't fix the rigid-body physics engine. At best you get marginal improvements (which I find unlikely: almost nobody in game design has to deal with large rigid-body assemblies). At worst, you discover that Unreal has a less efficient rigid-body engine... because much like the developers of Unity, they never saw it as a priority, because who would be nuts enough to design a game requiring assemblies of hundreds of linked parts?

EDIT: You know, there's a real parallel to scientific computing here. "Man, these physics are brutal, and my senior Ph.D. student needs to write his/her thesis soon. Can we make some approximations to make it run faster?"

Edited March 1, 2020 by Starman4308

[sturmhauke]

Physics is inherently an O(n^2) problem; you have n objects within a certain simulation range, and they're all potentially affecting each other, hence, n^2. All you can really do to simplify the problem is to reduce the size of n, which is why KSP has things like physics range limits, spheres of influence for celestial bodies, and orbits on rails. Parallel processing is theoretically useful in breaking a large physics problem up into subproblems and running them concurrently, but in practice there's a huge amount of overhead and much more difficult to write and debug. There was an older thread on that topic a while back if you want to go looking for it.

[Starman4308]

10 minutes ago, sturmhauke said:

Physics is inherently an O(n^2) problem; you have n objects within a certain simulation range, and they're all potentially affecting each other, hence, n^2. All you can really do to simplify the problem is to reduce the size of n, which is why KSP has things like physics range limits, spheres of influence for celestial bodies, and orbits on rails. Parallel processing is theoretically useful in breaking a large physics problem up into subproblems and running them concurrently, but in practice there's a huge amount of overhead and much more difficult to write and debug. There was an older thread on that topic a while back if you want to go looking for it.

In my field specifically, Particle Mesh Ewald is an excellent O(n*ln(n)) approximation of long range electrostatics in molecular simulation. I know octree approaches are common in astronomical simulations as well. They're approximate, but in many circumstances, you can approximate N-body problems in O(n*ln(n)) or even O(n) time.

The specific problem in KSP style rigid body physics is a combination of self consistency (making parallelization hard) and nobody having worked out an easy approximation to solve the system of constraints involved. There might be academic work on similar systems, but it sure hasn't percolated down into game engines.

Edited March 1, 2020 by Starman4308
Less sarcasm.

[runner78]

15 hours ago, Starman4308 said:

Switching game engines won't fix the rigid-body physics engine.

Right, as an example by default Unreal uses the same as Unity. Namely NVIDIA PhysX. So far i know Unity use a newer and faster version as Unreal. 

With Unity ECS it comes also 2 other Pyhsic engines, "Unity Physics" as default for ECS with and as an option to switch to Havok. Havok also develope the Unity Physics.

[Starman4308]

3 hours ago, runner78 said:

Right, as an example by default Unreal uses the same as Unity. Namely NVIDIA PhysX. So far i know Unity use a newer and faster version as Unreal. 

With Unity ECS it comes also 2 other Pyhsic engines, "Unity Physics" as default for ECS with and as an option to switch to Havok. Havok also develope the Unity Physics.

KSP does not use PhysX for the rigid-body physics, and PhysX would be poorly suited to it. GPUs are good for lots of relatively simple independent or loosely-coupled calculations (e.g. particle GFX), but the sort of rigid-body physics we're talking about is tightly-coupled and difficult to parallelize, something that's much better suited to CPU calculation than GPU calculation.

NVIDIA PhysX is also, you know, proprietary NVIDIA software, and isn't about to run on AMD or Intel hardware.

[Incarnation of Chaos]

4 hours ago, Starman4308 said:

KSP does not use PhysX for the rigid-body physics, and PhysX would be poorly suited to it. GPUs are good for lots of relatively simple independent or loosely-coupled calculations (e.g. particle GFX), but the sort of rigid-body physics we're talking about is tightly-coupled and difficult to parallelize, something that's much better suited to CPU calculation than GPU calculation.

NVIDIA PhysX is also, you know, proprietary NVIDIA software, and isn't about to run on AMD or Intel hardware.

Unity also implements it on the CPU, so it's not even a factor. 

[runner78]

6 hours ago, Starman4308 said:

KSP does not use PhysX for the rigid-body physics, and PhysX would be poorly suited to it. GPUs are good for lots of relatively simple independent or loosely-coupled calculations (e.g. particle GFX), but the sort of rigid-body physics we're talking about is tightly-coupled and difficult to parallelize, something that's much better suited to CPU calculation than GPU calculation.

NVIDIA PhysX is also, you know, proprietary NVIDIA software, and isn't about to run on AMD or Intel hardware.

KSP use PhysX for the lokale physics (vessel) PhysX is Open source, and work on every CPU. GPU physics has the problem with the large CPU<->GPU communication overhead.To create a custom rigid-body physic engine is immposible for an indie gamestudio. Not even large AAA Studios. Most AAA Games using Havok.

[Delay]

This thread is giving me headaches. Unity is not a good, versatile engine? No doubt that's why it's used in a LOT of games, from the 2D "Cuphead" to "Keep Talking and Nobody Explodes" and KSP!

These performance issues are entirely related to what the game is doing, and what the game is doing is entirely in the hands of the developers. Unreal Engine 4 is not bad because certain games "from the developers of a certain franchise (that I loved so much)" don't know how to optimize their code and/or how to use a physics engine.

This is dangerously misinformed, as the previous SEVEN PAGES have shown time and again.