Impact of PhysicsSignificance on Part-Count vs Frame-Rate

[StahnAileron]

I've been designing space stations as of late. One thing I try to do with them is give them proper self-illumination so I can actually see them at night. (I have plenty of mods and one of them make night-time in space pretty dark...)

My first station is over 200 parts and counting (still missing a few nodes.) I think about 20% of the part count is just lights and RCS ports. I just realized the lights and RCS are physics-less. Does that affect the physics processing KSP does since the mass and drag are just added to the parent part? I'd like to think it makes it a little easier, but this is KSP: I can't assume the best case scenario regarding how it does things.

I'm asking because the surface lights from B9 aren't physics-less. I like their looks, so I tend to spam them a bit on my designs (spaceplanes especially.) I'm thinking of using them on my next station, a small-medium fuel depot. This one is a bit more practical at about 75 parts for better loading and processing. But I realize about 18 parts are already just lights.

So does PhysicsSignificance help with physics processing & frame-rates to any degree or is it purely based on part count? (The >200-part station is now chugging along at about half real-time now.) It if leans towards part count, I'll probably redesign the fuel depot to use Stack Inline Lights for lighting. (And/or saying screw it and launch it as one vessel rather than building it modularly; those docking ports add up...)

EDIT:

1 hour ago, bewing said:

[...] Physicsless parts are indeed a little easier to calculate. But they still have colliders -- and that is the worst physics calculation, so the reduction is small.

[...] light sources reflect off things, so you have a lot of raytracing and whatever to deal with for each point source. [...] Your lights are going to add significantly to your GPU load. Not your CPU load.

Then could you clarify the MET color indications? Could a yellow indicator be cause by an overworked GPU? For the record, I'm on an i7-4771 @ 3.5GHz w/ 16GB RAM & an AMD HD7990.

My game runs slowly (less than real-time) but is playable (not choppy at all) with the >200-part station. I just took at look at the station with the Debug Menu's Performance graph. Says I'm running at 21FPS, but movement and camera control is quite smooth and even (other than the stutter from GCing every few minutes.) I'm guessing the 21FPS is more physics frames processed than visual frames rendered/displayed? 21 Physics FPS seems to jive with the approximately half real-time rate I was guessing at.

Oh, this was with nearly max graphics settings other than Texture Quality (Half) and ground scatters (Off) and with forced DX11 in this case (trying to save on RAM; had Out of Memory crashes as of late from editing the station). I think my Physics Delta in the settings is 0.04...

EDIT2:

1 minute ago, bewing said:

Yes, AFAIK it's supposed to flip to yellow whenever your frame rate drops below (1 / PhysicsDelta). And your framerate is determined by the worst of either your GPU load or your CPU load (including all the computing power devoted to any other tasks on the machine, of course).

Huh... I just my Physics Delta. I was at 0.05 for 21FPS. I tried it out with extreme settings and got:

• 33.2FPS @ 0.03 (consistent and smooth)
• ~10FPS @ 0.12 (choppy & stutters between 8-11FPS)

I never did quite understand how Physics Delta worked. I did notice that the frame rates I wound up at equal 1/Physics Delta though. Is that setting effectively a "minimum frame rate" setting or something?

Edited April 9, 2017 by StahnAileron
Addressing an answer.

[Gaarst]

I don't know about PhysicsSignificance, but in your particular case, I know that lights are quite laggy.

[bewing]

As Gaarst implies -- there are two sources of lag. Physics and graphics. Physics is much less laggy than it used to be (your 200-part station probably wouldn't run well in version 1.0.5). Physicsless parts are indeed a little easier to calculate. But they still have colliders -- and that is the worst physics calculation, so the reduction is small.

However, many people's machines are graphics-bound, not CPU-bound. And light sources reflect off things, so you have a lot of raytracing and whatever to deal with for each point source. So that's the main point here. Your lights are going to add significantly to your GPU load. Not your CPU load.

[bewing]

3 hours ago, StahnAileron said:

Could a yellow indicator be cause by an overworked GPU?

Yes, AFAIK it's supposed to flip to yellow whenever your frame rate drops below (1 / PhysicsDelta). And your framerate is determined by the worst of either your GPU load or your CPU load (including all the computing power devoted to any other tasks on the machine, of course).

 

 

[Gargamel]

One method I have found to reduce part count is to use a welding mod.  (I don't have a link, sorry).  Once I established the fact that I could build a station in space, and had made quite a few, I figured I'd cut out the busy work and HyperEdit a station into place.  I build the majority of the structure in the VAB, and then using the weld mod, turn it all into one piece.  Lights, ports, anything that needs to work, I add after the weld.   With some designs, that reduces part counts by >50%.   I still end up launching and attaching modules later, but the lag is nominal then. 

I understand if some people would consider this cheating (and I guess it is), or would be opposed to it on purely aesthetical reasons.  But when I've been there done that, I don't feel the need to reinvent the wheel every time around.  

If you do want to build in space, there is the Konstruction mod (I believe that's what it's called).  It has a bunch of cranes and rover parts, but it's main use to me is the docking ports.  The are nearly identical to the stock parts, but when you have to of them docked, you can have them "weld" together, and they disappear, fusing the modules together, and reducing your part count by 2 each time.   Depending on how you build your stations, that can save you 20-30 parts each time. 

[fourfa]

Spamming lights has definitely caused slowdowns for me around space stations due to the raycasting problem.  Honestly, you need less that you probably think.  The cabin lights can do a great job of outlining the station outer limits, if you place them right.  And they don't cost so much computationally, as they don't cast light on other objects.

The other thing that slows down stations is docking ports.  Open docking ports are continuously scanning the space in front of them for other ports to initiate docking with.  On a big station, this might be dozens at a time.  I've found stations to run much smoother when I converted to almost entirely retracting ports.  I don't use many parts mods, but there are packs out there with retracting 2.5m ports (I can't confirm that this would halt their CPU load though).  I tend to make docking port adapter covers for unused 2.5m ports - one 2.5m port, the thin 1.25-2.5m thin structural adapter, and a 1.25m shielded port on that.  When I need to open up a 2.5m port, I have a RCS tug to move it out of the way.  While the adapter isn't connected, it's adding load, but I find the 2.5m port attachments tend to be semi-permanent anyway.

Both of these things seem to be far more important than part count, physics significance, etc.  Welding can definitely still help but be aware that strange things can happen when kraken forces (these days often from autostruts suddenly changing path when the heaviest part changes) flow through welded parts.

Edited April 9, 2017 by fourfa

[Spricigo]

@gargamel those links?

[Gargamel]

9 hours ago, Spricigo said:

@gargamel those links?

Yes sir! Muchos gracias!