Discussion: Optimization

[Hupf]

On 16.7.2016 at 8:45 PM, Red Iron Crown said:

How would the game know what the stresses or forces are without calculating physics in the first place?

 

4 hours ago, Red Iron Crown said:

Not to speak for Claw, but Unity does not support PhysX running on the GPU (nor would it be of much benefit for the type of physics a KSP craft represents).

 

Why not use a (non-PhysX, but e.g. OpenCL/DirectCompute/... based implementation) low precision physics simulation on the GPU whereever possible and recalculate (or estimate error a priori) results with double precision on the CPU if certain error margins are exceeded? I'm not familiar with how this would be able to be integrated with the Unity Engine, but in many instances of scientific physics simulation it boils down to find out which parts can be calculated with lower precision (the game already does this with the "on rails" approach).

[Red Iron Crown]

Just now, Hupf said:

Why not use a (non-PhysX, but e.g. OpenCL/DirectCompute/... based implementation) low precision physics simulation on the GPU whereever possible and recalculate (or estimate error a priori) results with double precision on the CPU if certain error margins are exceeded?

How would you know the error margin without calculating the higher precision to compare it to? For that matter, the PhysX side of KSP physics doesn't use doubles anyway, and the reason it wouldn't run well on a GPU is not because of precision.

[Hupf]

9 minutes ago, Red Iron Crown said:

How would you know the error margin without calculating the higher precision to compare it to? For that matter, the PhysX side of KSP physics doesn't use doubles anyway, and the reason it wouldn't run well on a GPU is not because of precision.

Numerics. http://www.math.cornell.edu/~demlow/425/chap5.pdf

Physically speaking: for example, heat transfer in a reentry situation involves much higher temperature gradients (which are known a priori), so your error estimate will be several dW (pun intended) higher and a threshold would be in place to calculate this with higher precision.

OTOH, if all physics is on single precision anyways, then of course this point is partly moot. The question of why GPU isn't used then boils down to:

• The physics engine would have to be manually re-implemented
• The data structures and algorithms are badly parallelizable as-is and would have to be re-thought

Sooo... KSP 1.3?

[Red Iron Crown]

4 minutes ago, Hupf said:

The data structures and algorithms are badly parallelizable as-is and would have to be re-thought

Sooo... KSP 1.3?

I don't think a rework of the vessel structure is on the table for any KSP update. Maybe if there's a KSP 2.0 or something.

[Azimech]

10 minutes ago, Red Iron Crown said:

I don't think a rework of the vessel structure is on the table for any KSP update. Maybe if there's a KSP 2.0 or something.

And it shouldn't be. The current structure is flexible enough and a great learning opportunity for gradually integrating more elements of real physics, through mods. Stuff that don't exist yet but I hope to see in the (far) future are thermal expansion & aging, custom materials, fluid dynamics, wear etc.

If there is to be a KSP 2.0, I hope it will come 10 years into the future.

[steuben]

I tire of the forumite deving. <Rant> <Rave> <Froth mouthed screaming> <Rave> <Rave> <Milk a giant cow> <Rant> <Rant> <Froth mouthed screaming> <Breath> <Rave> <Rant> <Hack> <Hack> <Cough> You're all talking generalities here. It's specifics that matter.</grumpy old man>

That being said I propose something useful, for most involved. Let's take a suitably sized chunk of KSP code, for craft physics for example. Run up some performance stats for it, input and output parameters, language restrictions, etc.

Allow any who wish to, to try and better the code.

Submissions will be evaluated on, in no particular order or weighting, size, speed, memory use, elegance, readability, adherence to Squad coding standards, scalability, etc.

At the least there will be one out come, the amount of discussion about optimization and how it should be done will be lessened and will be focused.  And if we are very lucky something that will improve things will be generated.

In short: Hang out a nice safe piece of code, for step up or shut up time.

[cfds]

11 hours ago, steuben said:

In short: Hang out a nice safe piece of code, for step up or shut up time.

Starting with you...

[steuben]

I look forward to see your code as well, cfds.

[pandaman]

Well actually. What @steuben suggests isn't such a crazy idea.

In a nutshell, from how I understand it, it's...

 'we all have different ideas about what should be done, so let's all just have a go and see if any of our ideas actually work'.

Is it practical, or a feasible and sensible idea that squad would go for? That's up to them to decide, but there's a chance it could help, and at the very least it could be an interesting exercise for programmers to do and may even yield some benefits. 

Personally, my programming days died with the Sinclair Spectrum, so I won't be joining in the fun whatever. 

[cfds]

13 hours ago, steuben said:

I look forward to see your code as well, cfds.

Nope. You made the claim, you have to provide the proof.

Edited July 29, 2016 by cfds

[steuben]

 

17 hours ago, pandaman said:

 'we all have different ideas about what should be done, so let's all just have a go and see if any of our ideas actually work'.

Is it practical, or a feasible and sensible idea that squad would go for? That's up to them to decide, but there's a chance it could help, and at the very least it could be an interesting exercise for programmers to do and may even yield some benefits. 

Personally, my programming days died with the Sinclair Spectrum, so I won't be joining in the fun whatever. 

Pretty much. But we will need info and or code from Squad about it. Otherwise it is just the usual [vulgar metaphor redacted].

Mine never left VB6. But code is code, translating good code from one language to another is not a terrible task. Besides having learned how to code in a small, slow environment (by today's standards) isn't a bad thing for something like this.

[Stoney3K]

One of the things that really eats performance is the resource system, especially when you have ships that have a lot of fuel tanks, solar panels and other parts that consume and generate resources. One of the most interesting cases is a station, which is supposed to be 'steady state' in all aspects -- it shouldn't move around physically, and the total resource generation should be more (or at least equal to) the total resource consumption.

So give me one good reason why the game loop does a calculation of "Solar panel 124 adds 0.5 EC to the main batteries, repeating for solar panel 125...", running the resource logic on every single individual part of the ship? I suspect that can be easily lumped together on the craft loading, and the only resource calculation would be the net effect on the ship's resources for each cycle, instead of the resource effect of each individual part.

[pandaman]

54 minutes ago, Stoney3K said:

 

So give me one good reason why the game loop does a calculation of "Solar panel 124 adds 0.5 EC to the main batteries, repeating for solar panel 125...", running the resource logic on every single individual part of the ship? I suspect that can be easily lumped together on the craft loading, and the only resource calculation would be the net effect on the ship's resources for each cycle, instead of the resource effect of each individual part.

My guess is it needs to check every part every time because stuff can change.  One particular solar panel may be in shadow and another partially obscured for example, and all that changes constantly as the sun moves across the sky.  Not to mention the unpredictable stuff like clumsy kerbals knocking bits off.

[Stoney3K]

Just now, pandaman said:

My guess is it needs to check every part every time because stuff can change.  One particular solar panel may be in shadow and another partially obscured for example, and all that changes constantly as the sun moves across the sky.  Not to mention the unpredictable stuff like clumsy kerbals knocking bits off.

Which usually only involves one part, or in most cases, involves the entire craft with the total resource generation/consumption being a function of the situation of the entire craft, e.g. its orientation with respect to the sun. This is similar to calculating aerodynamics, you can also have a voxel-based model which determines how much resources are generated or consumed as a function of <condition X> on the craft. That is simple matrix math, which is a hell of a lot faster to calculate in each frame than executing a specific PartModule for each specific part on the craft. For example, if you have a 100 batteries and 50 RTGs, that's 150 (managed) calls to the respective PartModules in each physics frame, where the actual number of unique PartModule calls is no more than two. The batteries and RTGs can be lumped together into one big RTG and one big battery.

The biggest CPU hog on the resource calculation is the fact that new objects are being created and objects are being destroyed each frame, where the actual action is nothing more than adding or subtracting numbers. Only if a part is manipulated or destroyed, the transfer function which determines the resource behaviour will change. So if a Kerbal knocks off a solar panel, the solar panel coverage needs to be re-calculated, but it does not have to be re-calculated every single frame.

[pandaman]

@Stoney3K

I get your point that it would be more efficient to calculate for a whole craft as a single entity rather than for each part, but I think that's an over simplification. 

Like many players, I have a station in Kerbin orbit.  When I right click on any of the solar panels to find out how efficient they are it's not unusual for them all to be different, and they are constantly changing as the station orbits and rotates.  I know this is a bit different when the ship is on rails, and I may well be wrong here, but even then I don't think it's as easy as being able to assume that all panel a are at the same exposure etc.

[Stoney3K]

3 minutes ago, pandaman said:

@Stoney3K

I get your point that it would be more efficient to calculate for a whole craft as a single entity rather than for each part, but I think that's an over simplification. 

Like many players, I have a station in Kerbin orbit.  When I right click on any of the solar panels to find out how efficient they are it's not unusual for them all to be different, and they are constantly changing as the station orbits and rotates.  I know this is a bit different when the ship is on rails, and I may well be wrong here, but even then I don't think it's as easy as being able to assume that all panel a are at the same exposure etc.

That's my point: They don't have to be. Just as each panel is illuminated differently in graphics, which are rendered at lightning speed, the amount of sunlight falling on coordinate (X,Y,Z) of the entire ship is easy enough to calculate. For your solar panel example, If you have a matrix that computes the amount of ElectricCharge on coordinate (X,Y,Z) as a result of there being a solar panel there (or not), the net EC generation for that physics frame is simple matrix multilplication, which is really, really fast. Only if a solar panel gets destroyed, retracted or moved around, the matrix needs to be re-calculated to evaluate the total amount of potential generation on the craft. (The actual math involved is actually exactly the same as the lighting logic, so you could even cheat and use the light value for something like that. With some GLSL-fu, you may be able to do it on the GPU.)

You can do the same with aerodynamics for stuff like intakes, and the amount of mathematics is a lot less than cycling through each part and wait for it to add or subtract a bread-crumb of resources. The properties of the craft don't change unless some part is altered, like an intake that is closed, a fuel cell that is turned off, or a solar panel that is retracted.

[steuben]

Feels like a trade of clocks for memory. It might be a good trade... 

The value of solar light hitting each part will either have to be held and then passed to the charge generating function, or be added to the part variable itself.

Or at the cost of slowing down the whole lighting cycle, embed the charge calculation right in there. If light = solar and electric.generation = true then zap += light.solar* C. Or words to that effect.

But then this might all be moot if the lighting functions and values are inherited from Unity and are either inaccessible, unmodifiable, or both.

[Mjp1050]

On 7/16/2016 at 0:07 PM, TheDestroyer111 said:

Then please explain why KSP is the only game I know that doesn't require mods to randomly crash even if I don't do anything special (like building 10000 parts ships), regardless of my specs.

I'm a bit late to this party, but I would like to point out that I can crash Skyrim consistently on my Xbox. Sooo... no, KSP is not the only game that crashes randomly. Even a big-budget game from a major game developer can be unstable.

 

Also, is there anything that we players could do on our end to make KSP run better? I'm thinking maybe some use of Task Manager to disable resource hogs in the background... Does Windows have any nonessential functions that can be turned off?

[Megadeath]

On 31 July 2016 at 0:45 PM, steuben said:

-snip-

Or at the cost of slowing down the whole lighting cycle, embed the charge calculation right in there. If light = solar and electric.generation = true then zap += light.solar* C. Or words to that effect.

 -snip-

The technical discussion is beyond me, but from a purely aesthetic this appeals to me greatly.

[TheDestroyer111]

On 7/31/2016 at 7:15 AM, Mjp1050 said:

I'm a bit late to this party, but I would like to point out that I can crash Skyrim consistently on my Xbox. Sooo... no, KSP is not the only game that crashes randomly. Even a big-budget game from a major game developer can be unstable.

 

Also, is there anything that we players could do on our end to make KSP run better? I'm thinking maybe some use of Task Manager to disable resource hogs in the background... Does Windows have any nonessential functions that can be turned off?

if YOU caused the crash then its not a random crash like what you have in KSP. atleast by my definition of it

Edited August 2, 2016 by TheDestroyer111

[Northstar1989]

Great discussion guys!  Keep it up, and maybe a dev will notice!  

[asmi]

On 21/07/2016 at 2:18 AM, cfds said:

Honesty, I don't know why KSP treats all the Lego blocks as separate physical entities. The whole stack of a rocket should be monolithic. In real life aeronautics there is little flex besides at the wings of planes so why simulate it here?

You never flew on, say, Boeing-767? 

[Carraux]

On 30.7.2016 at 11:03 PM, pandaman said:

My guess is it needs to check every part every time because stuff can change.  One particular solar panel may be in shadow and another partially obscured for example, and all that changes constantly as the sun moves across the sky.  Not to mention the unpredictable stuff like clumsy kerbals knocking bits off.

Two things are involved here: A) how much light the panel gets and B) where to store the generated electricity in.

The first problem is not that difficult. In fact, Unity offers some functions to determine if any object is between one object and another. This function is not that fast, but there is no need to compute this in each and every frame.

The second one: This is resource flow computing.This logic is heavily used in KSP (fuel, electricty consumption and charging). And KSP computes this every time. In our case here, every time KSP will look for the right battery to store the energy there. Every time. Because situation may change, either due to staging, or the battery is full. Or it is deactivated, And if KSP compute the resource flow in each frame for every part involved, it automatically can handle all craft changes, without any additional implementation costs, Nothing will be forgotten. Very straight forward. Unfortunately, it is also very slow. And much more unfortunately, it creates temporary memory objects which must be discarded afterwards, resulting in micro stuttering (you may find a very good explanation here)

In this case the Great Prime Directive Of Game Programming is violated here: Compute once, store result and resuse it. Recomputing is only needed on situation changes. Determining this changes and acting appropriate may be a little more to code, but it's worth the work.

Edited August 8, 2016 by Carraux

[Carraux]

Addendum: I have just read in the developer blog the following entry:

A more specific update in this area comes from Jim (Romfarer) and Nathanael (NathanKell) who have spent this week rewriting the resource flow system. Under the hood many systems have changed: Resource requests and GetConnected requested are now cached per set of crossfeeding parts, and per resource ID. On top of that the event system created in 1.1 for when PartResources change state (flow mode, empty, nonempty, full, etcetera) is used so that the caches are updated in place rather than recreated. All in all, this means there is a small spike on staging but so long as the part count doesn’t change and crossfeed rules don’t change the actual lookups are extremely fast and garbage-free.

So maybe this problem is wiped out in the next release. I hope so!

[Corona688]

On 8/2/2016 at 2:09 PM, TheDestroyer111 said:

if YOU caused the crash then its not a random crash like what you have in KSP. atleast by my definition of it

So, when KSP crashes it's their fault, but anything else is his fault.  Good to know.