Jump to content

Thoughts and suggestions on multi-thread performance (and lack of)


Recommended Posts

Hey folks,

So yeah, I'm grumbling because my 103 part ship gets yellow clocks at 1x timewarp. 

On a Ryzen 1600X with 32gb memory and an m.2 Samsung 960 Pro. This is not a slow PC. Most often my task manager says 11-13% of CPU and 30-40% of GPU in use. We are so badly bound by single core performance that I can't help but wonder if this is even on the developer's roadmap for things to review?

I mean, I think I get it; you initiate a force from an engine or a wing or an impact, and the game then propagates that force up all the linkages and sees what bends and what breaks and what generates lift or drag. I get that that has to be done linearly, but... is it all required, and is it optimised? I'm just looking to explore questions like:

  1. For regular flight (non-impact scenarios), does the game identify the weakest load-bearing part and stop when it gets to and clears it (on the assumption that all other parts beyond must be fine)?
    1. Does it split the vessel into three around the weakest part, test the links either side as if the segments were rigid, and stop there if nothing breaks?
  2. Do parts in cargo bays (which are not load-bearing) get properly ignored by the physics calcs unless that bay is open or a new collision is detected?
  3. Do this expensive set of physics calcs actually add to the game? What if all vessels were simply assumed rigid unless colliding with another vessel/astronomical body? Do we love noodle rockets and explosions so much that it's worth the fps drop of not treating them as rigid bodies that do not bend or flex ever?
  4. Has there been any thought of grouping parts into groups of N, tackling the physics as if they were a single part with the structural strength of <minimum segment> and only breaking the calculation down further if something causes issues, and only in the section that broke?
  5. Does the game separate calculations like lift from bending/breaking forces? Spaceplanes are particularly laggy and I can't help wonder if we (do/could do) frame-by-frame calculations for the bending forces, and the lift and the drag in separate threads, with the lift and drag's calc's taking the previous frame's bending outputs. Yes the lift would be a frame behind, but would the player notice at 25+ fps that would result from threading it? Or even at 2 fps.

Intended to be constructive! I am a little tipsy so this may not be the best organised list, but I'm genuinely interested whether performance is at all on the radar.

I'm also debating whether or not to swap my Ryzen 1600X for an Intel 8086K with it's 5ghz single-thread boost. Which would be about 25% more performance. Which I would quite like. Because yes I am that dedicated to KSP that I will spend hundreds of english pounds to make it run better.

 

Edited by eddiew
Link to comment
Share on other sites

I wonder if it would be possible to have a "simplified connection physics" mode where all connections are treated as perfectly rigid, as if the whole ship was welded. It might remove a little of the challenge--you could build any old ridiculous contraption and have it be perfectly solid--but on machines that have trouble with part counts it'd absolutely be worth it. If my experience with welded torus stations is anything to go on, such a mode would make a huge difference in playability.

Link to comment
Share on other sites

6. Do devs posess actual profiling data for the large vessel case? Can they publish it here?


To the OP:
3). You would get another game, though it would indeed perform better. Joints are integral part of KSP from the very beginning, a lot of players like it, it will not change. What you propose is the path Space Engineers took btw. Space Engineers performance may be assessed by this meme (rather old though, but you get the idea, there is always trouble when game has any physics): https://imgur.com/PetIf9p
4). https://forum.kerbalspaceprogram.com/index.php?/topic/96670-14-253-2018-04-06-ubiozur-welding-ltd-continued/
5).

> Does the game separate calculations like lift from bending/breaking forces?
yes. Before the integration step is made, KSP game code appends forces (drag, lift, gravity) and torques (SAS) to rigid bodies that will be accounted for by PhysX iterative solver. All that and joints and collisions on top of it are then calculated in said PhysX iterative solver under no direct control of KSP devs.

> I can't help wonder if we (do/could do) frame-by-frame calculations for the bending forces, and the lift and the drag in separate threads, with the lift and drag's calc's taking the previous frame's bending outputs.
yes, though Unity makes multithreading unreasonably hard. Measures that make it possible under Unity may well outslog the benefit of threading. Profiling is king here. Also, it implies devs caring at this point. Game's life cycle is far from it's zenith.

> Yes the lift would be a frame behind, but would the player notice at 25+ fps that would result from threading it? Or even at 2 fps.
yes. Such integration scheme is not physically correct and makes little sense. There will be planes that should fly and wich will not fly under such physical laws, they will become unstable. Control code will stop working as it is now. Manual control will feel unnatural with additional lag. It would be a nightmare.

Edited by Boris-Barboris
Link to comment
Share on other sites

53 minutes ago, Hotaru said:

I wonder if it would be possible to have a "simplified connection physics" mode where all connections are treated as perfectly rigid, as if the whole ship was welded. It might remove a little of the challenge--you could build any old ridiculous contraption and have it be perfectly solid--but on machines that have trouble with part counts it'd absolutely be worth it. If my experience with welded torus stations is anything to go on, such a mode would make a huge difference in playability.

All machines have trouble with part counts, the question is whether the player builds things big enough to notice :/  I find it frustrating that on my old 2500K I used to try to keep spaceplanes below 80 parts, and on my new 1600X I try to keep spaceplanes below 80 parts. This... has got to be tackled at some point for the game to progress...

And yeah, I've welded many things in the past, but the mission in question with it's just-over-100 didn't feel worth the effort... until it was yellow clocking for 5 RL hours. The big silly stations in my current playthrough/comic strip are a single part with the exception of whatever's been docked to them at a later date :) 

38 minutes ago, Boris-Barboris said:

6. Do devs posess actual profiling data for the large vessel case? Can they publish it here?


To the OP:
3). You would get another game, though it would indeed perform better. Joints are integral part of KSP from the very beginning, a lot of players like it, it will not change. What you propose is the path Space Engineers took btw. Space Engineers performance may be assessed by this meme (rather old though, but you get the idea, there is always trouble when game has any physics): https://imgur.com/PetIf9p
4). https://forum.kerbalspaceprogram.com/index.php?/topic/96670-14-253-2018-04-06-ubiozur-welding-ltd-continued/
5).

> Does the game separate calculations like lift from bending/breaking forces?
yes. Before the integration step is made, KSP game code appends forces (drag, lift, gravity) and torques (SAS) to rigid bodies that will be accounted for by PhysX iterative solver. All that and joints and collisions on top of it are then calculated in said PhysX iterative solver under no direct control of KSP devs.

> I can't help wonder if we (do/could do) frame-by-frame calculations for the bending forces, and the lift and the drag in separate threads, with the lift and drag's calc's taking the previous frame's bending outputs.
yes, though Unity makes multithreading unreasonably hard. Measures that make it possible under Unity may well outslog the benefit of threading. Profiling is king here. Also, it implies devs caring at this point. Game's life cycle is far from it's zenith.

> Yes the lift would be a frame behind, but would the player notice at 25+ fps that would result from threading it? Or even at 2 fps.
yes. Such integration scheme is not physically correct and makes little sense. There will be planes that should fly and wich will not fly under such physical laws, they will become unstable. Control code will stop working as it is now. Manual control will feel unnatural with additional lag. It would be a nightmare.

I'm aware of and do use the welding mod :)  I just didn't expect to be needing it with 103 parts :huh: 

Thanks for the info how how the game code runs :)  Sounds like Unity really needs to get a grip on threading, since it is the future. And the present, if we're honest. 

Not sure I understand why having the lift/drag a frame behind the bending is a particular problem... does it result in runaway forces because the next frame's bending is calculated based on the previous frame's drag+lift? I'm not a game coder, I'm basically just chucking out ideas that seem sane on the surface but may not pass inspection :) 

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...