• Content Count

  • Joined

  • Last visited

Community Reputation

24 Excellent

1 Follower

About runner78

  • Rank
    Rocketry Enthusiast

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  2. The newer PhysiX has better multicore optimizations, but i don't the details and also has it's limits. KSP 2 need to chunk parts together as one physic body (or some other tricks), otherwise are high part count not possible.
  3. I played with 1.8 and had also some stack overflows after a long game running. I don't played 1.9 yet. I was better then in the past, but there would still be room for improvements here.
  4. So far i know, Unity run Physics on a seperate core, but the mainthread have to wait for it. Orbit calculation can be an bottleneck. I have played once without deleting debris, the performance got pretty bad after a while (only 30-40 debris, on a AMD Ryzen). After deleting it was back to "normal". I once testet simple orbits with DOTS, 200,000 small rocks, on 30fps (single precision). And orbit calculations are run always. My point here is: physics is the greatest bottleneck, but not the only one.
  5. KSP is more then just rigid-body simulation. Don't forget orbital simulation, Sound, UI, Animations, Rendering (CPU part), Terrain, Aereodynamic and some other gamelogic. KSP 1 using camera stacking, that is also a large perfomance killer. I don't know is KSP 2 using Unity 2019.3 now, that have a PhsyX upgrade from version 3.4 to 4.1
  6. The Job system is a Tool, and developer need to learn how to use the tool. You can also use the Job system to run jobs with Burst on the main thread, for small jobs its faster as the overhead for the scheduling. On of the main advantage of the job system and multithreading in general is not only to process one task parallel on multiple core, but process different tasks at the same time. You can also split a task in small jobs with dependencies each other, and maybe some subparts can be parallelized. One thing that KSP can do well in a job would be e.g. orbital calculation. All vessels and debris are simulated in the background. And with Bust and SIMD optimization it could also very fast.
  7. 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.
  8. One part of DOTS is Unity's Job system that uses all CPU cores and is already production ready for about 2 years. And the Bust compiler, that make the jobs at least so fast or faster as C++ code, is also relesed for a while now. I hope, they use it, it would be a waste of potential.
  9. 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.
  10. DOTS are C# job system, Burst and ECS, the first 2 are production ready and the ECS core are planned for Unity 2020.1. For Unity 2019.3 comming is close to production ready ECS core, and previews for animation, sound and multiplayer. During the Unite 2019 they presented a DOTS demo with animation, sound and multiplayer. KSP2 could using DOTS in some cases like orbit simulation (that does not use any physic engine) With an early ECS preview i have testet it with simple newton gavity, i have simulatet arount 200,000 visible objects at 30 fps.
  11. Yes, that immediately free it, a garbage collector make no sense in this case. With .Dispose() the allocator knows the memory is no longer in use. A garbage collector check objects whether they are in use or not, that is expensive, not the clearing itself. The later part are to use different allocators for specific use cases. The concept of different custom allocators exists in C++ and often used in games.
  12. No, there is no garbace collector in background. If you use the native collections, you must clean the memory yourself with the .Dispose() method. Unity give you errors if you forgot or choise the wrong allocator.
  13. Tell them SQUAD to deactivate it for the next Update.
  14. Unity has his own native collection like NativeArray and NativeList. This memory is managed by Unity native and has no garbage collection.