That was also my goal when I started thinking about creating my own algorithm that would use spherical coordinates and actually store all the data in a tree based fashion. But I haven't got far enough with implementation as I switched to other more pressing ideas like my Silver GUI library that unfortunately hasn't seen any progress for the past six months or my texture making program which needs a major core rewrite in order to allow myself to include few more desired features that can't be implemented at current state.
Yes doing things in real time can become quite difficult due to the large amount of processing required. That is why initially I wasn't even thinking about trying it. But my latest design idea is moving in this direction. I figured that until I put this idea into implementation the computer would probably be strong enough for it to work
The main problem with KSP is that it is using PhysicsX engine in software mode. Why?
Main problem is that PhysicsX uses single stage physical simulation. What does this means? Since in KSP all ships are made from connected parts physics are calculated in a way that you first calculate new position of root object based on the forces applied to it and then proceed calculating new position for other objects in a tree like manner. This is limiting the processing of any such ship to a single thread. Also until the latest versions KSP only used single world physics simulation (all ships were simulated in a single thread) while in latest version of KSP it is possible to simulate separate ships in separate threads.
Now it KSP would be perhaps using some different physics engine that uses two stage simulation there would not be so much performance issues. Why?
Because with two stage physics simulation you use first stage to just calculate new objects position and store that information without moving of those objects right away. Because of this there is no need for your to calculate physics for multiple connected objects in any specific order so you can easily spread the work across multiple threads. And once you have calculated new position for all object you actually move all those objects to their new position but you do this in the second stage.
So as noted above the main advantage of two stage physical simulation is the ability to spread the work across multiple threads.
But it does come with its own disadvantages. Main disadvantage is the increased memory requirements as you need to be able to store both old and new position at the same time.
And the second disadvantage is that second stage also requires some processing time so that the cumulated time to simulate physics and move one part/object to new location is actually higher than in one stage physical simulation. But with clever implementation of double buffering it is possible to reduce that to minimum.
And even if you could not reduce the additional time needed by the second stage so that processing physics and moving one part/object to new position would take twice as long you could still get almost 50% better overall performance if you can spread all that physics simulation to four separate threads.
Frankly I'm guite surprised why there aren't many physics engine that actually utilize this two stage physics simulation approach.
If I would be better at math I would probably try and make Pascal based two stage physics engine but I'm actually pretty bad at math
But if you are interested I'm prepared to work with you on implementing one provided that you take care about math and I'll try to take care about logical part of implementation
That is understandable due to recent events in your life that you mentioned before. But stay strong.
Bookmarks