Another optimization for sub-assemblies & physic

[Justin Kerbice]

Launching a crazy beast on orbit today (just 495 parts for the final stage) with "only" 16 small landers docked, I have a steady 5-7 fps, which is very low, it was even better with launcher, 8 fps, and I just thought: why not considering sub-assemblies as a whole in term of physics ?

It might save some precious CPU resources for what really matter.

I think it would be also possible to group parts into small unique physic entities like collider for a bunch of small parts (ie: flat solar panels, lights, ladders, ... are not supposed yet to be ripped of where they are placed, even in reentry). Waiting for Unity team to move in the right way (if they will do that one day !)

[vexx32]

Why? Because it's not that simple. What if you crash? Suddenly the game has to choose whether or not to destroy the entire part, or break it up first (somehow) and then destroy individual parts. When exactly do you "merge" the parts? What if your subassembly contains six stages? Do they suddenly stop functioning?

[Sirrobert]

What if my subassambly IS my launcher, that I put under the lander after building it? Does that make the launcher a solid block?

[Whirligig Girl]

Yes, under the op's rules, but that's bad.

[Frank_G]

Maybe parts could be designated as payload, so they can be calculated as one piece and only being used when specific conditions are met (like fairings away, decoupled etc.) to avoid metagaming or other problems.

[Lord Orion]

Look up UbioZur Welding mod alows u to simplify things like fuel tanks and wings. Id link it if I was not on my mobile. Best possible fix tho, the game engine alowing use of all cores of a processor for calculations. I know not every one has a computational beast of a computer but still 4 cores is becoming common.

[Kruleworld]

When exactly do you "merge" the parts?

I'd suggest when FPS drops below 10!

[Frank_G]

I'd suggest when FPS drops below 10!

That would ruin the consistency in the simulation... it must be a system, that will not switch from mode a to b in an uncontrolled way. It wont help you anything, if the vessel you are piloting would suddenly react totally different to your inputs while the game speeds up by an unknown factor. BOOM would be the certain result, and silly flighpaths, and and and... To get somewhat like this feeling right, is very a delicate task that already from the start could not being solved without compromises. Maybe this will be more achievable, after having a look at the new upcoming joint behaviors in .24.

[Justin Kerbice]

Today I just have an idea regarding situation and abnormal frame drop due to a few (about 10) vehicles in the vicinity (one alone don't have so much parts, they work great and frame rate was ok):

as physics need to be "stabilized" when switching to something, I can't understand why there is so much frame drop due to physics only in such case, so why not just ignore all vehicle farer than x meters (x is a settings parameter), such ignored vehicles might be seen as a mere "box" with a mass and a basic colider if really needed, especially when they are not in sight (behind for example).

I mean 3D objects can be as they are, full of nice looking parts, but regarding physics, it just be like KSC buildings = "nothing" (just a box stuck on the ground), as there is not frame drop at all with buildings displayed and they still have a collider.

It's worth a shot (by Squad) I think, so we could definitely consider this as an optimization or a dead-end.

All of this is regarding no improvement in Unity layer.

[Red Iron Crown]

as physics need to be "stabilized" when switching to something, I can't understand why there is so much frame drop due to physics only in such case, so why not just ignore all vehicle farer than x meters (x is a settings parameter), such ignored vehicles might be seen as a mere "box" with a mass and a basic colider if really needed, especially when they are not in sight (behind for example).

As I understand it, that's pretty much how it works currently. Objects further than 2.5km (IIRC) away go on rails and aren't physically simulated, though the range isn't adjustable.

[vexx32]

Indeed. That's pretty much exactly what's done. From memory, I think Harv said something about objects even within the 2.5km radius not being fully in physics mode until either you pass really close to them, or they're in atmosphere, or something else happens that requires them to have physics simulated. So... yeah, basically, that's what's already done.

[FREEFALL1984]

Maybe parts could be designated as payload, so they can be calculated as one piece and only being used when specific conditions are met (like fairings away, decoupled etc.) to avoid metagaming or other problems.

That might not be too bad an idea, the payload is generally pretty static and unused during launch, once the player decouples it could then revert to individual part physics saving sweet FPS during launch

[Justin Kerbice]

Indeed. That's pretty much exactly what's done. From memory, I think Harv said something about objects even within the 2.5km radius not being fully in physics mode until either you pass really close to them, or they're in atmosphere, or something else happens that requires them to have physics simulated. So... yeah, basically, that's what's already done.

so there is something weird around, why fps drop so much when more than x "things" (=vessels, rovers, living debris, landers, ...) are in the vicinity ?

Or the "close to them" is too big (>= 500m) ?

It's looks like there is a threshold and when parts count/vessels count is over it, boom,game became almost unplayable (try to dock manually at less than 8 FPS).