Anyone else think KSP 2 might be overly ambitious?

[Chilkoot]

On 10/18/2019 at 1:35 AM, Francois424 said:

I'm not against it as long as it's toggle-able... I usually keep the default things on (like antenna range and remote without reception dying) but I like having the option of turning it off if it starts annoying me.
Keep it simple tho.  Water, Air and Snacks.  I wouldn't mind having a large greenhouse station or a dome on my ships to make snacks, and/or having to stop at an asteroid or 2 everynow and then for water.
Just not every game.

Star Theory has said that they don't want to "punish players" for just leaving a colony on its own and focusing on some other undertaking, so I suspect any KSP2 in-game life support will be rather minimal and automated like requiring production and reprocessing modules in your ground bases.  Adding life support in general to KSP 1 changes the game *completely* and usually introduces a ton of micromanagement, which isn't for everyone.  Without cryogenics, some longer missions are essentially impossible.

Personally, I don't want strict life support in the base game, but I would at least like to see engine-level support for survival and resource processing loops as we see in quasi-overhaul mods like the USI suite.  Being able to implement these features via mod without bringing the game to its knees would really open the door to some fun mechanics.

[magnemoe]

2 hours ago, Chilkoot said:

Star Theory has said that they don't want to "punish players" for just leaving a colony on its own and focusing on some other undertaking, so I suspect any KSP2 in-game life support will be rather minimal and automated like requiring production and reprocessing modules in your ground bases.  Adding life support in general to KSP 1 changes the game *completely* and usually introduces a ton of micromanagement, which isn't for everyone.  Without cryogenics, some longer missions are essentially impossible.

Personally, I don't want strict life support in the base game, but I would at least like to see engine-level support for survival and resource processing loops as we see in quasi-overhaul mods like the USI suite.  Being able to implement these features via mod without bringing the game to its knees would really open the door to some fun mechanics.

As I understand KSP 2 will have an simple life support system, think snacks. 
However any colony worth its name as in build by parts and can refuel ships will have independent life support. They can also export life support resources as in snacks to ships. You might have to build for this, as in needing more greenhouses than needed fro your population. 
System is not that unrealistic, you can get water and oxygen from ISRU fuel and oxidizer anyway. But not food.
In real life Your main focus would be salad, meat, and fish is easy to freeze, grains don't even require freezing. Vegetables are harder, its an reason why scurvy was an problem. 
Nowday is an quality of life issue. 

[Unixsystem]

It seems to me that most of the potential problems are 90% solved by improving the base performance of the game. KSP1 by all accounts seems to be a game that is built on an extremely rocky foundation and even so we've seen modders add most of the features KSP2 is promising, usually only limited by the fact that you can only build ships/stations/bases so big before the game starts to fall apart. 

With the ability to start essentially from scratch and build the engine to support large part counts (and MP) from the beginning, most of the remaining work is just on the design end to make it actually be fun. Not a trivial issue, but a lot easier than wrestling with flaky technical issues and it's an issue that they have copious mods to look at and see what works and what doesn't. 

I certainly don't think it's a guarantee that KSP2 will love up to its potential, but assuming that they aren't outright lying about their work rebuilding the engine I don't see any reason that what they are promising is unreasonably ambitious. That said, healthy skepticism is always good with an unreleased game. 

[mattinoz]

I do wonder if Level of detail (LOD) which seems to be the greatest buzzword for graphics Engineeers at the moment was the main breakthrough in making the engine faster and more robust for KSP2. I could see how having an engine be able to discern when nothing interesting is going to happen in part of the calculation until a future threshold and just ignore till then would be a big win for the game.  
 

I do wonder if it’ll lead to other advantages. If say they are situationally loading assets could they do the same with mods creating per save modding.

 

[k00b]

Quote

"You start at our new Kerbal Space Center, which is actually at the same location on Kerbin as it was in the original game," explains Simpson. "And then all the planets in the Kerbolar system continue to be present in enhanced forms. And then, as you continue to progress up the tech tree

Simpson describes KSP2 as the 'Yes, and…' version of the original game

...it's a KSP1 re-hash using unity again; watch the "meet the developers" video, they are texture re-moddeling...

On 10/13/2019 at 12:38 AM, Brikoleur said:

The GPU isn't the bottleneck for KSP. Single-thread CPU performance is.

CPU-Z is telling me all cores and threads are being used, and below 30% (ryzen 2600) are you sure it is not the GPU having to render light from absolutely everywhere ("space") or did they change to "multicore" 1.8 ?

thanks

 

[Guest]

2 hours ago, k00b said:

CPU-Z is telling me all cores and threads are being used, and below 30% (ryzen 2600) are you sure it is not the GPU having to render light from absolutely everywhere ("space") or did they change to "multicore" 1.8 ?

I'm sure. KSP has pretty simple lighting and caps the number of light sources quite low, you can verify this by sticking a bunch of lights on your craft and switching them on one by one -- after a certain point, some will start switching off to make room for the others.

The issue is rigid-body physics. These can't be multithreaded (at least not easily) and computing the forces acting on each part of your craft gets exponentially slower with more parts. Things get especially messy with stuff like bases, which involve interactions of craft with surfaces, and an unusual number of craft inside the physics bubble.

KSP2 is definitely a yes-and game, but they are addressing the bottlenecks holding KSP1 back directly (and no, Unity isn't it). It remains to be seen how well they'll succeed at it, but they've made it clear that they understand where the problems are, and are doing their best to solve them.

[k00b]

i was meaning texture rendering in a vast space (ie. pixel reflections / shading in relation to the sun etc) not "lights" and hardware monitor is indicating all CPU cores are processing, at non full load (and not stressing out a single core) - so i am confused.

1 hour ago, Brikoleur said:

The issue is rigid-body physics. These can't be multithreaded (at least not easily) and computing the forces acting on each part of your craft gets exponentially slower with more parts. Things get especially messy with stuff like bases, which involve interactions of craft with surfaces, and an unusual number of craft inside the physics bubble.

woow woow down shoot down KSP2 this far prior to release

[Unixsystem]

5 hours ago, k00b said:

i was meaning texture rendering in a vast space (ie. pixel reflections / shading in relation to the sun etc) not "lights" and hardware monitor is indicating all CPU cores are processing, at non full load (and not stressing out a single core) - so i am confused.

woow woow down shoot down KSP2 this far prior to release

Rendering in space is vastly easier than rendering something like a first person game set in a detailed ground environment. The game's skybox is just that - a 2d box (or sphere) set at infinite distance from the objects in the game, and it requires essentially zero graphical horsepower to render. 

That means that when in flight you have at most 2 polygonal things to render: the ship (or ships) in flight and a nearby planet if present (more distant planets are so small on screen that they usually amount to at most a few hundred pixels). Even high part count ships in KSP are extremely geometrically simple by modern hardware standards, so calculating lighting and shadows from a point light source like the sun is relatively simple. Adding dozens of lights onto the craft itself can and will result in a much more dramatic performance hit, but you need to really go ham with light sources to tax a modern GPU.

Planets don't begin to render shadows until very low altitudes, and even when they do the landscapes are extraordinarily simplistic and the textures are low resolution (finally being updated to higher quality but still nothing to write home about). Turning on terrain scatter can increase this quite a bit, and if you start adding mods like EVE, Scatterer and high resolution texture packs, you can absolutely start becoming GPU bound, but in vanilla you need to be running a very low end GPU to hit the graphical limits before the much more common CPU ones. 

In response to your last comment, I assume you are inferring that he's saying that the physics problem is unfixable and as a result KSP2 doomed, but that's not the case. KSP1 was built by amateur game devs and was not optimized for the level of performance it demands given the type of game it has become. At this point fixing KSP1 would essentially require tearing apart the entire engine and rebuilding from scratch, which would be way beyond the scope of an update for a game this old. KSP2, however, is being built from scratch, and so they can build the entire physics engine around the unique problems that the first game constantly runs into. It remains to be seen how successful they will be, but they've made it clear that performance is a key development focus so I'm cautiously optimistic. 

Edited October 20, 2019 by Unixsystem

[k00b]

3 hours ago, Unixsystem said:

Rendering in space is vastly easier than rendering something like a first person game set in a detailed ground environment.

thankyou; one (without knowledge...) would assume - that with a fps (with solid ground), "graphics" can be pre-rendered from prest ?, whereas in space there is no ground and thus light rendering has to be more "on the fly" due to dimensions omitted by the "solid ground" ("preset gun with sun above" vs. rotating spaceship, sun location "undefined" etc ?) - i.e. some [terminology] about multidimensional lighting equations in kerbals would be more complicated then a grass and sky scene or no ? or is that todo with CPU processing ?

thanks.

 

[mattinoz]

15 hours ago, Brikoleur said:

The issue is rigid-body physics. These can't be multithreaded (at least not easily) and computing the forces acting on each part of your craft gets exponentially slower with more parts. Things get especially messy with stuff like bases, which involve interactions of craft with surfaces, and an unusual number of craft inside the physics bubble.

What if the issue wasn't rigid-body physics?

Be seeing a lot of talk about using particle physics engines to simulate rigid-bodies by binding groups of particles into and approximate shape.  Seem as a plan well suited to KSP given the "Thrust" of the game is throwing particles out the back of the craft to go forwards. Well that and particle engines handle orbital and gravity mechanics very well.

[Guest]

3 minutes ago, mattinoz said:

What if the issue wasn't rigid-body physics?

Be seeing a lot of talk about using particle physics engines to simulate rigid-bodies by binding groups of particles into and approximate shape.  Seem as a plan well suited to KSP given the "Thrust" of the game is throwing particles out the back of the craft to go forwards. Well that and particle engines handle orbital and gravity mechanics very well.

Sounds like an interesting idea, certainly worth exploring.

[Guest]

On 10/10/2019 at 6:44 PM, Compsagnathus said:

• I would suspect it would take a lot of effort to beautify all of those assets and add effects such as "unique" explosions based on the parts involved.

I expect by "unique" they actually mean something like 6 different explosion graphics which will be assigned to parts depending on their function or resource contents (ie. fuel tanks have the fireball explosion, structural parts just have bits of metal and paint flying outward).

The term unique is often used in marketing to mean only "a set of possibilities" rather than physically generated from data like the geometry and energy involved in an event.

Edited October 21, 2019 by Guest

[Renegrade]

I suspect it is over-ambitious, and I worry about the consequences for future space-y games if they do faceplant....but on the other hand, you must have some sort of ambition to accomplish something big.  Like the original Moon landing.

[Unixsystem]

23 hours ago, k00b said:

thankyou; one (without knowledge...) would assume - that with a fps (with solid ground), "graphics" can be pre-rendered from prest ?, whereas in space there is no ground and thus light rendering has to be more "on the fly" due to dimensions omitted by the "solid ground" ("preset gun with sun above" vs. rotating spaceship, sun location "undefined" etc ?) - i.e. some [terminology] about multidimensional lighting equations in kerbals would be more complicated then a grass and sky scene or no ? or is that todo with CPU processing ?

thanks.

 

I think there may be some fundamental misunderstanding about how rendering works. I'm not an expert by any means, but my understanding is that with traditional rasterization (aka 99% of all games) everything starts from the geometry that is being rendered. So if you're landed on a planet, you have polygons for all of the terrain, KSC buildings, and your ship whereas in space you essentially only have your ship, and then potentially a planet or two which will be very low poly due to level of detail scaling. 

 

Once the GPU has the actual polygons in place, it will then look at the available light sources and shade the polygons that will be visible from the current camera position. So in a typical scene the only major light source is going to be the sun, which is treated as a point source essentially infinite distance away. This means that in space, the game only needs to render lights coming from one source, on a handful of geometrically simple objects, which most of the time is only taking up a small fraction of any given frame (the rest is just skybox, which is basically free from a rendering perspective). If you add lights to your ship that ramps up the calculations quite a bit, but you need a lot of lights to really start making a difference. 

 

On land, you also need to compute the lighting for all of the terrain and ground scatter around your ship, but again the terrain in KSP is so simplistic compared to modern games that while more work than a space scene, it's still trivial for most modern GPUs. 

 

In terms of your comments about the dimensions of these calculations, they are always the same regardless of where you are. Just because you as the player have no real reference frame for where exactly you are l, the game always knows your exact coordinates, rotation, and location relative to the sun. The calculations are equally as intensive on Kerbin as they are out floating out past Eeloo. If the game can render your location on the map screen, then it knows where to place the Sun to properly light up your ship. 

 

EDIT: The tl;dr here is that graphical performance in a visually simplistic game like  (stock) KSP is going to be primarily based on the number of polygons on screen at any given time. In space, that will almost always be less than on a planet, and generally in order to stress a decent GPU you would need to load up so many parts that you would start hitting CPU limits long before any graphical ones. 

Edited October 21, 2019 by Unixsystem
Tldr

[k00b]

2 hours ago, Unixsystem said:

(the rest is just skybox, which is basically free from a rendering perspective)

didn't think about that; thankyou! (nor that the sun is just a big polygon in the sky...).

[Unixsystem]

On 10/21/2019 at 6:30 PM, k00b said:

didn't think about that; thankyou! (nor that the sun is just a big polygon in the sky...).

Really unless you get awfully close to it, I doubt that Kerbol is even rendered as a polygonal object. At great distances it most likely acts solely as a light source with a 2d texture acting as the flare that you actually see in the sky. At worst I'd imagine that from Kerbin's orbit or further if it is rendered in 3D at all it's likely represented by no more than 1 or 4 pixels on any common resolution. Once you get to Moho or closer it may actually start to be noticeably polygonal, but even then it's so difficult to get close that I'd have to imagine that it's the least detailed object in the solar system. 

[Starhawk]

Not in the least.

Happy landings!