Anti-Lag: Freezing Physics Of Stationary Designs

[GrantZ9001]

So, I'm about to send a mission to Duna (pic related), but the one major problem I'm facing is the amount of lag a full base suffers. It makes building the base and moving around the base a drag rather than an enjoyment. My suggestion to alleviate this lag would be the ability to freeze at least parts of the physics calculations of stationary modules. Not sure how hard this would be to implement, but I think it would make base building a lot more fun since you wouldn't have to blindly stare at the part count of each module.

BTW most of the modules in my example are sub-130 part modules and I'm running a decent rig (i5 2500K@~4,4GHz,GTX670,8GB DDR3,OCZ Agility3 120GB SSD), so hardware shouldn't really be a problem. I of course could go bare-bones with the designs, but where would the fun be with that

Would anyone else wish to see something like this implemented?

Edited August 30, 2013 by GrantZ9001
typos in the title lol

[Nuke]

i definitely would. id love to just be able to lock a part or collection of parts to the terrain.

[TheCanadianVendingMachine]

Well, nothing is stationary unless if you are in a perfect Geo Sync orbit. I mean perfect, as in 0 m/s of movement. Even then, you are orbiting the Sun.

[Person012345]

Well, nothing is stationary unless if you are in a perfect Geo Sync orbit. I mean perfect, as in 0 m/s of movement. Even then, you are orbiting the Sun.

Or you know, on the ground like he said. Also being in orbit of the sun doesn't mean anything in KSP unless you're in it's SoI and not something elses. No sun-related physics (unless you count sunlight blocking) are calculated for an object in kerbin orbit for example.

[GrantZ9001]

Yeah, I didn't bother with going into details what really stationary would mean, but I mainly meant landed objects with a 0,0m/s velocity on the surface of planets/moons. I know it would have an impact on the realism of the game, but I personally think smooth gameplay comes first in this case. Hopefully this could also get rid of the bug of solar panels often falling off upon loading in atmos. All of this should of course also be completely optional; something you'd apply manually.

Edited August 30, 2013 by GrantZ9001

[innovine]

The same kind of optimizations can be applied to space stations and zero-g vessels which are not currently being piloted. Eventually a station should dampen itself out and enter into a steady state. It may be rotating, but if you are not piloting it it's not possible (afaik) to impart a force on the station that would require physics and structural integrity calculations, at least until you collide/dock with it. I'd very much favor disabling these calculations, or simplifying the whole station into a single rigid body.

[Bessy]

even then it could be made to lock the object unless movement Eg if something happens to knock a large collection of parts like a base the game could say ok movement physics active on this collection but it means aproaching a large station u get no lag till u start interacting with the docking port then its who cares the game will pull the ship in dock and be done lag or no lag it would be a great improvement for when I'm trying to dock to my 300 part refueling station

I wouldn't want it to de activate untill all movement was gone tho wobble etc but once its all gone why waste time untill something major changes

[Harguinxx]

Vessels are loaded if they are at less than 2000 meters from you, I don't think that these can be improved without eliminate the beautiful physical interaction between objects. (an impact or a docking to an object can't be processed if the object is not loaded)

What maybe can be upgraded, is to simplify automatically the structure into very schematic region, little larger than the vessel itself, so until you are very close the whole ship isn't loaded....

Maybe it would help with the gameplay experience, but it mean a lot of work from the devs, and an inevitable and not smooth decay of the fps just before collide. I think that these could really work very well in land bases.

But in fact the real problem is not the game optimization, the real problem is that modern processors and OSs are developed for being optimal in multithreading conditions, and these game is not. I know that this was posted one million times, and is in the "do not suggest" list, but is still the major problem of the game optimization, in my opinion of course.

[Zeroignite]

I am in favor of this. FPS is a big limiting factor in base-building density, which seems a little silly to me since the base modules are all sitting stationary on the surface.

[Sean Mirrsen]

There's this absolutely insane little thing called Detonate, which is entirely about constructing and blowing up buildings.

This game has a very noticeable function, wherein any connected collection of parts "settles in" once it no longer experiences any changes in stress. This means that you are free to look at a complete skyscraper as it is standing, and at a partially destroyed building or pile of smoldering rubble once it's all over, but as soon as you hit the structure with enough force that it could create a change of stress, you are seeing a massive slowdown (relative to the complexity of the building) as the physics on it start up and start doing their thing.

Something very similar could be done to landed or orbiting craft in KSP. Once the craft's parts' movements fall below a certain threshold, and the force acting on the craft remains constant (i.e. gravity), the craft could "lock in", turning off the part interactions and locking all parts in place for as long as no force is being applied to it. This would allow stationary structures such as bases and stations to be far less CPU intensive, as their physics would consist of only the collision meshes of the whole craft checking against any moving objects and the terrain - provided nothing is being done to them, i.e. docking.

[Harguinxx]

There's this absolutely insane little thing called Detonate, which is entirely about constructing and blowing up buildings.

This game has a very noticeable function, wherein any connected collection of parts "settles in" once it no longer experiences any changes in stress. This means that you are free to look at a complete skyscraper as it is standing, and at a partially destroyed building or pile of smoldering rubble once it's all over, but as soon as you hit the structure with enough force that it could create a change of stress, you are seeing a massive slowdown (relative to the complexity of the building) as the physics on it start up and start doing their thing.

Something very similar could be done to landed or orbiting craft in KSP. Once the craft's parts' movements fall below a certain threshold, and the force acting on the craft remains constant (i.e. gravity), the craft could "lock in", turning off the part interactions and locking all parts in place for as long as no force is being applied to it. This would allow stationary structures such as bases and stations to be far less CPU intensive, as their physics would consist of only the collision meshes of the whole craft checking against any moving objects and the terrain - provided nothing is being done to them, i.e. docking.

Not sure if it's so easy, a dev would know better than us, but how do you will count an impact if the ship borders are don't loaded??? you need to load the borders of each part of the craft in order to interact with them.

The game you mention probably takes a lots of parts in a single structure (easy when you are talking about a flat wall), and when the structure receive a force, then splice the structure in a thousand substructures and apply the force in the ones corresponding to the impact vector...

If you do the same in these game and you simplify the ship as a cylinder (for example), when the vessel isn't actually an exact cylinder, you will not collide in some places you should collide, you will receive an impact when there is nothing, the docking will be a way more buggy than now, and you will lose the part of realism that make this game awesome.

In conclusion, a dev would know better, buy I really don't see the way to apply your idea without making the interaction between ships a way less awesome, because I don't think that the system used in the game that you mention is applicable in KSP, nice idea though.

[Sean Mirrsen]

No, the game literally freezes all of the parts in place, and unfreezes them all once a sufficient force is applied - because the building's collision is not simplified at all, but the interactions between them, including the mechanics of stress and intercollision, are no longer running - saving massive amounts of CPU time, because those inter-part physics calculations are what comprises like 90% of the physics load of the craft.

Basically, once "locked in", the craft becomes static. It stops in its last rest state, and does not run inter-part collisions because no parts are moving anymore. It can still run heat exchange, it can still run science gear and gather power (though gathering resources may not be so easy, as it'll force recalculations as the storage tanks filling will increase the stress on the craft), but the most taxing part of the physics - the treating of each part as a separate physics object and seeing if it collides with anything - no longer occurs.

[Munbeast]

This would be pretty simple to do, it would require a bit of time tweaking to achieve the best results in different situations but the actual principle is an easy one to implement.

Squad doesn't seem to do any optimisation at the moment, hence the crazy loading times, physics lag and memory usage. I'm not sure if it's lack of experience in that area, or if they are waiting for the game to be almost complete and optimising then, which is a sort of sensible thing to do, but sucks for people playing the game in the meantime.

[Technical Ben]

Vessels are loaded if they are at less than 2000 meters from you, I don't think that these can be improved without eliminate the beautiful physical interaction between objects. (an impact or a docking to an object can't be processed if the object is not loaded)

What maybe can be upgraded, is to simplify automatically the structure into very schematic region, little larger than the vessel itself, so until you are very close the whole ship isn't loaded....

Maybe it would help with the gameplay experience, but it mean a lot of work from the devs, and an inevitable and not smooth decay of the fps just before collide. I think that these could really work very well in land bases.

But in fact the real problem is not the game optimization, the real problem is that modern processors and OSs are developed for being optimal in multithreading conditions, and these game is not. I know that this was posted one million times, and is in the "do not suggest" list, but is still the major problem of the game optimization, in my opinion of course.

Go back and read your post. I see posts like this on every consideration. There is at least 1 contradiction in your reply. "Vessels are loaded if they are at less than 2000 meters from you" and "but it mean a lot of work from the devs". If we already have it in game, the physics calculation could be set to a proximity of, say, 100m. Which is a single variable change and not a lot of work. (Actually it would be even better to scale depending on the speed of approach and the size of the object. While this takes a little more work, the variable can be replaced with a "class" that checks first if the craft is within 2000m, then it's speed, then it's size, then outputs "run physics yes/no". ).

It's an idea, and it takes roughly the same amount of effort to implement as most ideas do.

PS, mostly it's down to waiting till the right time to "optimize". As refactoring, changing engines, changing artwork, changing levels, changing gameplay all mean new and different methods and requirements for optimization. So until more of the game is settled, it could be wasteful to polish the parts that will be replaced later on.

Edited August 30, 2013 by Technical Ben

[Sean Mirrsen]

There's actually a massive difference between the "lock-in" I propose and the physics packing that objects beyond physics range undergo. The difference is that a locked-in object still physically exists, and all of its parts are still distinct and can be interacted with. The only things they don't do is move or check for collisions/stress from each other. A locked-in object is also locked into its gravity-deformed position, and will not suffer additional stress from unlocking, whereas a packed object is packed into a rest state. You can even put a Kerbal into and out of a locked-in craft without unlocking it, provided it stands on the ground stably enough and the Kerbal is not smashing into it at 20m/s. The lock-in is a much more dynamic state of being, and just making the physics packing distance shorter will do nothing good - it will just increase the lag if you have to switch between several closely standing buildings.

[Harguinxx]

No, the game literally freezes all of the parts in place, and unfreezes them all once a sufficient force is applied - because the building's collision is not simplified at all, but the interactions between them, including the mechanics of stress and intercollision, are no longer running - saving massive amounts of CPU time, because those inter-part physics calculations are what comprises like 90% of the physics load of the craft.

Basically, once "locked in", the craft becomes static. It stops in its last rest state, and does not run inter-part collisions because no parts are moving anymore. It can still run heat exchange, it can still run science gear and gather power (though gathering resources may not be so easy, as it'll force recalculations as the storage tanks filling will increase the stress on the craft), but the most taxing part of the physics - the treating of each part as a separate physics object and seeing if it collides with anything - no longer occurs.

If you are sure that the 90% of the physics calculations are between parts of the same vessel, even if is totally static, I agree with you.

I think these have to be implanted with caution, because maybe ruins the realism of the collisions, but yes, on paper it seems a very good idea, you have my approval (if it means anything XD).

+1