runner78

Unity is working on it https://forum.unity.com/threads/feedback-wanted-streaming-virtual-texturing.849133/ A simple way would be to simply add a crater to the heightmap.

Many games only compile the shaders when the game starts. And when loading a level, much more happens than just reading from the hard drive. The assets have to be unpacked, loaded into the scene, and graphic assets also sent to the GPU. Start scripts run to prepare the scene, in KSP e.g. when starting a vehicle it has to be reassembled from the save / craft file. Unity DOTS has the concept of subscenes, which was designed to save the data of the subscene exactly as it is in the RAM and then read it 1:1 into the RAM. But this is in develeopment.

I think its an unfai comparison. This is just a quick assessment of the lack of time, but the Unity project is only intended to show what performance is gained through porting GameObject to DOTS, the excample itself is generally not optimized. Presumably unoptimized DOTS/Hybrid versus optimized native example? The question is also which version of the ECS render he is using, there is V2 version which is faster than the old one, which is more for static object optimizer, back then it was created for the megacity demo. (A mobile version of it was also shown once)

I have to look at the unity profiler to see how PhyX behaves. It would be ideal if PhsX would generally run in its own thread. Apart from PyhsX, a problem with KSP is the partmodule system, basically a component system inside of unity GameObject components. If you have a vessel with 200 parts with average 3 modules, you have 600 modules update per frame. (There are also other methods, but I haven't modded KSP for a long time and I've forgotten) Depending on the action of the part module, this can quickly lead to performance problems. The 600 modules are also affected by GC, Unity GameObject not, they have a native counterpart and are created / deleted native.

KSP1 use Unity 2019.2 so it also use a newer PhisX version. the problem for KSP is that the vessels are on big joined "thing", so multithreading is limited. KSP1 started with PhyX 2.x, newer Unity version have PhyX 4.x with more performance and options.

Games that use ECS are already being developed, for example: https://store.steampowered.com/app/1272320/Diplomacy_is_Not_an_Option/ In the Unity forum I also reported that other games with ECS are in development, but Unity could not or was not allowed to say anything. KSP1 has started with Unity 3.x, Unity has evolve since them. One problem of KSP1 is the core of the game is build of that old Unity version and cannot simply be fundamentally changed. Unity has now new tools, newer C# version/framework. PhysX in Unity is multithreaded since Unity5.

Its solve some performance issuses, but kills KSP feeling

SwitchPort()->Resourses()->isKSP2Indie() I think nowadays the word "indie" is used to describe the size of the budget, rather than the actual independence status. Private Devision is a publisher of indie games.

According to this definition, games like CyberPunk 2077 should also be considered indie games. Developer and publisher is the same, i.e. independent.

I don't know the exact number but according to LinkedIn, Intercept Games has 10-50 employees and 18 profiles exist. It's still indie for me.

I have a little hope after the delays, ECS has time to grow and KSP2 can use it for some parts. There are already games in development that use ECS, so it's not entirely out of the question. We don't know at the moment which gameplay elements KSP 2 will have, but as I said, I think all of this together is too much for the Switch, without having to change or remove gameplay elements.

KSP 2 is not an AAA Game, it's an Indiegame with limited resources. KSP doesn't have the amount of potential players like other AAA games, that wouldn't be profitable. What is the point if you spend 2 days at the end of a logic optimization for .05ms at the end, if you also save .04 with Burst with 2 hours? This effort is not worth it for "small" games, the budget is not enough. This also raises the question of how many potential players would there be on the switch? If you have to spend 50% more for a switch optimization for maybe 5% more players, who don't cover the 50%, then it just doesn't pay off. I don't think it's that easy, planet terrain is generated on the fly depending on your position. You can certainly optimize a lot here and reduce the quality, but that is still the calculation time that you have to factor in. And even if you split calculations over several frames, they take up computing time on the CPU and at some point it ends and calculations no longer keep pace. Not too bad for visual things, except that it's unsightly. Fuel flow when flying, that's what you need when the engine uses up fuel, it can't be calculated so easily over several frames, unless you accept inaccuracies, in the worst case the engine fails for no reason. Whereby with smaller calculations that doesn't bring anything except overhead. Anyway, that was just an example of small things that have to be calculated. Are you sure? KSP is a physics based game, and physics are CPU intensive. To avoid large rockets / planes, a modern PC can be pushed to its limits, and KSP2 wants to make even larger vehicles possible, so good optimization is needed for PCs. There is hardly any room left for a console whose performance even lags behind modern smartphones.

I also saw that the Switch only has 3GB of RAM available for gaming, shared for GPU and CPU.

Bust has an inspector that display the generated native code and give you also warning if not possible to vectorizing the code. Manual SIMD optimization can be time consuming, AAA Games have entire teams for that, where only the optimization team probably has more programmers than the entire KSP programmer team. KSP2 is still an indie Game. Burst give you performance out of the box and if you know what you're doing, you can get even more out of it. With weak hardware you can optimize as much as you want, at some point you reach the limit and you have to remove or simplify features. Optimization won't be enough, we also don't know what else has to be calculated in the background. We only consider the obvious parts of the game here. There is also the Terrain / LOD system. Fuel consumption / distribution, deltaV calculations. Each one is just a small thing, but everything accumulates together.

I think the job system has less overhead as other solutions (its designed for game), is't GC free and the core of the jobsystem is native, not C#. C# Task has GC and Context switches. Is ok for business applications, but have an impact on games. The job system uses workerthreads and can schedulte jobs that can run without delay between jobs. And manage also dependencies between jobs. This is where the burst compiler comes into play, burst compile the C# jobs to native code for the taget Platform (AOT). Uses clang/llvm to optimize the code and uses SIMD. In some cases ist even faster as "default" C++ code. but definitely faster than mono. Unity has also IL2CPP to compile the game to native, without Mono. Brings some performance advantages, but modding becomes more difficult. I not claim it can't run at all. I claim it can't run with the current/future featureset. You would have to "optimize" and simplify too much, so that the feel of the game will change or the game will be a completely different one.

Switch has 3 usable CPU cores (so far i know) Mainthread: 1 Rendering: 1 Physics: some task are multithreaded Job system uses all cores except for the core where the mainthread is running. If the job system is occupied and there is free capacity, jobs can also be carried out on the mainthread-core. With 3 cores on Switch, there are only 2 job workerthreads. And one of the worker thread share the core with the rendering thread. Even with jobsystem, there is simply a limit for parallelization. And don't forget: only 1 GHz ARM cores. At the moment we just don't know what has to be calculated, but I think that KSP has to be crippled if you have to run it on the switch. And every such small calculation accumulates and what you don't notice on a desktop PC can suddenly become a problem on the switch.

Don't forget, the orbits is one part of many others that run on a frame, and you only have a few milliseconds per frame, and if you simplify the orbit calculation too much, it becomes too imprecise. With modern Unity you can using the job system and burst and calculate much faster, but only in the limits of the hardware. I hope the part system from KSP 1 will not be adopted because it is anything but optimal. It's best to design the game for the lowest target Hardware from the start, especially if it's just an indie game. But if you develop a game for low / medicore hardware you have to make cuts. For other games you can simply reduce the range of vision, fewer effects, fewer details. With KSP, however, one would have to make deep cuts in the core simulation. In the end, despite optimization, it would only have the same feature-set as KSP 1.

I also don't know exactly what KSP calculates, but I not only believe the orbits of the current time, but also in the future to calculate when, for example, one leaves / enters the sphere of influence of a planet / moon. Unity is currently working a lot in the memory area. ECS e.g. relies on optimized memory layout and garbage collerctor-free API. Their burst compiler does not work with reference objects. The gc allocation is also reduced or completely removed for other APIs.

Newer Unity has a newer PhysX with a new solver type for better joins behavior, but i don't now about performance. If you join parts as on rigid body you have the problem how to decides with part are join together, is it decide by the game oder the player wile building? And also add complexity to building the vessel at runtime: remove the the original components and joints, create new parent with the new rigid body, calculate new mass an center of mass, rejoin the other parts. that is a potential for bugs and problems, and can have a negativ impact in vessel loadingtime. Especially for large structures. Even oribts are on "rail" they still have to be calculated. Even with my AMD ryzen i start from c. 60-70 vessels/debris to notice some performance drops. That would be a good approach for ECS and burst for faster calculations.

Havoc on Unity works only with ECS, it is not clear whether KSP 2 even uses this, probably not. KSP has also some background processes like calculate all orbits every frame/physic-steps (also in the future). If you wield all parts together as one rigid body, the CPU impact would be minimal, but also vessel behavior and gameplay would massifly change.

The graphic is not the (only) problem, KSP is CPU hungry. I have heard from other sources how many developers have problems porting their games to the switch due to poor performance. And indie developers in particular don't have the time and money for an extensive porting process. Presumably, KSP had to be limited so much, e.g. in terms of max number of parts, that the game is practically not the same anymore.

I don't think KSP would have to use Unity's HDRP for that. I think they are still using the old build-in renderer. But Unitys HDRP in a space game wouldn't look bad either, see Hardspace: Shipbreaker

The old Mono is slow, that was one of the reasons for Unity Burst to develop. Sooner or later Unity will switch from Mono to .Net5 +, which comes with RyuJIT and is a lot faster than Mono. These benchmarks do not reflect any game scenarios. As I said, SIMD is missing from the benchmarks, so bust can't show his power in this benchmarks. I'm only talking about burst, that has nothing to do with multhithreading, that's what you use the job system for. Bust compiled jobs can run on the mainthread. All this benchmarks are all single threaded. Automatic SIMD optimation (also calling auto vectorizing) has nothing to do with multithreading, but the SIMD registers of the CPU (SSE, AVX). They can be used to execute several identical arithmetic operations with one cpu instruction at the same time. This is particularly useful for position vectors. Without SIMD this would require 3 instructions for a 3D vector. The old Mono is slow, that was one of the reasons for Unity Burst to develop. Sooner or later Unity will switch from Mono to .Net5 +, which comes with RyuJIT and is a lot faster than Mono. These benchmarks do not reflect any game scenarios. As I said, SIMD is missing from the benchmarks, so bust can't show his power in this benchmarks.

Default C++ means if you compare the same algorithm gcc compiled C++ code , Bust compiled code should at least as fast and in some cases (in games many cases) faster then C++. Non-default C++ would be e.g. manual SIMD optimized code (very low level in C++), or with Clang/LLVM compiled (Burst based on Clang/LLVM). Burst tries to optimize the code automatically for SIMD, to do this you only use a limited subset of c# in burst job. which allows further optimization. There are also some benchmark cases where gcc/C++ is faster, but they don't benefit from SIMD, but games benefit greatly from SIMD optimizations. Her a are some benchmark: https://github.com/nxrighthere/BurstBenchmarks but it missing SIMD benchmarks.

Unity has the Job system with Burst, you can use Jobs in 3 modes. On multiple threads, on one separate thread or an the main thread. With burst you have performance sometimes faster then default C++. In some Tutorials Unity also pointed out the overhead and said that smaller tasks are faster to execute on the mainthread, An alternative is just a separate thread, which has less overhead than scheduling multiple threads. I think KSP run only at DX11. DX12 is not ready on Unity (They are working on it in the 2020 versions, but its still in an experimental state) Vessel Physics are not the only think in KSP. Orbital physics are another part, that can processed outside of the mainthread.