Question about the 1.1 update

[NecroBones]

[quote name='Algiark']Wow, what a thread this has become! It's a wonder anyone hasn't invoked Godwin's law and talked about how Nazis created the first physics simulation engine for their unfinished V3 rocket project :confused:[/QUOTE]

Thankfully, intentionally invoking Godwin's Law negates it, so we'll just have to see. ;)

[*Aqua*]

@TheTom
The GC doesn't occupy continuously an entire core on my system, only physics does. And we don't usually fly rockets made from only 3 parts.
Btw FAR isn't more efficient, at least not on my system. Whenever I had it installed my time display never showed green in atmospheric flight again. The lag was quite noticeable.

Also we are talking about the physics engine and whether in general using doubles instead of floats makes sense.



[quote name='Hannu']Physics in KSP is very simple to program and execute. If it would have programmed well, we could fly 10000 part ships [...][/QUOTE]
Then tell my why AGEIA and Nvidia weren't able to archieve that. They invested personnel, money and years to develop PhysX. Don't you think they know better about physics calculations than we both combined?


[quote name='Hannu'][...]and have much more accurate orbits and maneuvering, more sophisticated resource handling etc.[/QUOTE]
There's always room to improve something. A software is never complete.


[quote name='Hannu']Certainly it is very difficult, if not impossible, task to do properly if programmers does not have knowhow and special interest to that topic. It is just one boring thing which must be done before interesting things. They have probably taken the most easy (and maybe cheap) engine without thinking limits.[/QUOTE]
Programmers usually don't 'develop' stuff. They 're-use' stuff which experts developed. With stuff I mean basic software liky graphics engine, physics engine, audio subsystem, etc.
Yes, Unity was probably the cheapest game engine available back then (I think it's still the most affordable one) but it has a great advantage compared to other major game engines (examples: Unreal Engine, CryEngine, Anvil, Frostbite-Engine, etc.): It's the most accessable and adaptable of them. Need patched conics? Write 'some' code, throw it in and it'll work. This doesn't work with the other engines. They have pre-coded modules you have to use. If you need something out of the order you need an AAA-games like staff to create a new module.

It is said that 50% of all games use Unity. That number doesn't tell us about the quality of the game engine but it's an indicator that it does something 'more right' than other game engines.



[quote name='Hannu']CPU does not try anything by itself.[/QUOTE]
It does. It's called branch prediction. Here the CPU tries to predict which code is executed in near future and executes it if there are free resources. If it predicted wrong it discards the result. If it predicted right overall processing speed increases.


[quote name='Hannu']If we talk about physics model of KSP, that would not cost millions. Maybe tens of thousands are better approximation. It would probably take couple of months from some physics student. If there had been some interested or educated individual in KSP's development team they would probably have done it.[/QUOTE]
I'm not sure if I would let a student program such an important subsystem. Also you don't only need someone with a degree in physics (the one who knows which formulas apply), another one with a degree in mathematics (the one who transforms the formulas into something the computer can calculate efficiently) would also come in handy and then you'll also need a software architect (for overall software architecture & project managment), 2-3 software engineers (for software design, they break down all problems into easier ones) and a couple of programmers (who hammer everything into a computer) if you want to do it right. And I guess half a year of time is needed (for creating a concept, developing an architecture, fleshing out classes & interfaces, implementing, iterating and testing). As you see it gets expensive very fast.


[quote name='Hannu']I know that it is now economically impossible to fix it in KSP, but it is also interesting to discuss at general level. And maybe there will be KSP 2 or some reader decides to make a new game in spaceflight genre. I hope that they do not have to make same mistakes.[/QUOTE]
I sometimes wonder how a KSP 2 with the [URL="https://www.youtube.com/watch?v=fO7XhaTGDYg"]engine[/URL] from Infinity Battlescape would feel like. Imagine, no more scene switching, no need for a scaled down solar system, no trouble with floats, nicer graphics and probably no problem to have several solar systems you can go to, Newtonian physics already included, procedual generation of nearly everything which allows for billions of different star systems, planets and moons. Also rings with asteroids in it. <3 Edited November 25, 2015 by *Aqua*

[More Boosters]

[quote name='Algiark']Wow, what a thread this has become! It's a wonder anyone hasn't invoked Godwin's law and talked about how Nazis created the first physics simulation engine for their unfinished V3 rocket project :confused:[/QUOTE]


V3, the Verteltungswaffe (retaliation weapon) 3 was not a rocket. It was a long cannon.

If your claim about the first physics simulation engine is true, then it is probably about another rocket in the Aggregate series.

[Kerbart]

[quote name='*Aqua*']@TheTom
The GC doesn't occupy continuously an entire core on my system, only physics does. And we don't usually fly rockets made from only 3 parts.[/QUOTE]

There's a thread out there where someone claims he needs to code part of his program in assembler to make it run faster. This discussion seems to evolve around the same concept.

If the code spends most of the time in Physics, the [I]likely[/I] road to optimization is not to make physics faster, but to make less calls to it. The enormous inefficient way resources (the game ones like fuel and electricity, not the program ones like textures) are/were used suggests that it is not inconceivable similar gains can be made elsewhere.

Sure, we can throw in a faster Physics engine but that will only do so much. Most code doesn't scale linear when you throw more data at it. To make KSP run faster with more parts, the logic is what needs updating, not just some code optimization.

I have no clue how realistic that is, and if anyone claiming they can do it better really can. My late father told me [I]nothing is impossible for the man who doesn't have to do it himself [/I]and that's what I'm thinking when I read a lot of the responses here.

[Hannu]

[quote name='*Aqua*']Then tell my why AGEIA and Nvidia weren't able to archieve that. They invested personnel, money and years to develop PhysX. Don't you think they know better about physics calculations than we both combined?[/Quote]

They have had different goals. PhysX is not a real physics simulator. It helps to animate natural things which looks real enough for entertaining purposes in normal environment. It is generally much more difficult task, because there are very complex things (clothes, soft skinned lifeforms, particles in air etc.). KSP handles only low number of solid things in vacuum (or in very crude atmosphere model). That is why I say that KSP's physics is very simple (to program and to execute). KSP has no need for many very complex things PhysX can do, but on the other hand it has some special things PhysX can not do. As I said, PhysX is a wrong tool to this kind of game.


[quote]It is said that 50% of all games use Unity. That number doesn't tell us about the quality of the game engine but it's an indicator that it does something 'more right' than other game engines.[/quote]

90 % of games is much smaller and simpler than KSP. And probably their players does not use advanced mathematical tools to make predictions and compare game results to them.


[quote]It does. It's called branch prediction. Here the CPU tries to predict which code is executed in near future and executes it if there are free resources. If it predicted wrong it discards the result. If it predicted right overall processing speed increases.[/quote]

Branch prediction predicts conditional jumps. It has nothing to do with floating point instructions.

[quote]I'm not sure if I would let a student program such an important subsystem. Also you don't only need someone with a degree in physics (the one who knows which formulas apply), another one with a degree in mathematics (the one who transforms the formulas into something the computer can calculate efficiently) would also come in handy and then you'll also need a software architect (for overall software architecture & project managment), 2-3 software engineers (for software design, they break down all problems into easier ones) and a couple of programmers (who hammer everything into a computer) if you want to do it right. And I guess half a year of time is needed (for creating a concept, developing an architecture, fleshing out classes & interfaces, implementing, iterating and testing). As you see it gets expensive very fast.[/quote]

I wrote just about physics engine. Other things of game has needed much more crew and work. Graphics, user interface, game logic etc. are more expensive to develop than physics. And as far as I know, KSP started as a hobby project and it has still quite small staff. If there had been one math enthusiast, things could be different.

[quote]I sometimes wonder how a KSP 2 with the [URL="https://www.youtube.com/watch?v=fO7XhaTGDYg"]engine[/URL] from Infinity Battlescape would feel like. Imagine, no more scene switching, no need for a scaled down solar system, no trouble with floats, nicer graphics and probably no problem to have several solar systems you can go to, Newtonian physics already included, procedual generation of nearly everything which allows for billions of different star systems, planets and moons. Also rings with asteroids in it. <3[/QUOTE]

It could be great game, if it was not made too easy and simplified to get as much players as possible. Probably it is not realistic to expect that such game is suitable for me without mods. I want too engineering focused point of view (as you probably have noticed).

[Johould]

[quote name='Daid']AUCH. Your post just hurts from bad info.

Floating point calculations in modern CPUs are done in 80bits, always. 32bit operation? Don't care, first turned into 80 bits internally in the CPU before the math is done. [/QUOTE]

That's exactly how x87 floating point works, but those instructions are not quite modern any more. These days compilers prefer sse scalar instructions like MULSS to x87 instructions even for non-vector math. Those instructions only work at the precision of the arguments rather than the 80-bit extended precision x87 works in. Along with that, you do see performance differences - a 64 bit multiply is 4x the work of a 32 bit multiply. I haven't checked recently, but Agner Fog's instruction tables are probably still the place to look (actually, I wouldn't be too surprised if the performance of scalar operations has gotten pretty close, but vector ops will show).

I don't think AVX changed things back, but I'm not completely up to date on this stuff myself.

[Johould]

[quote name='Hannu']This is true only in very special conditions, which are rare in games (and almost everywhere). Simultaneous calculation demands that data is 8 dimensional vectors and n x 8 matrices. Typically there is 4 dimensional vectors and 4 x 4 matrices in physical simulations, 3D models etc. I guess that KSP does not use 8-vectors at all. If data must be rearranged for calculations it takes an advantage. As far as I know single 32 bit floating point operations are not faster than 64 bit operations (in modern CPUs).[/QUOTE]

You don't need 8-dimensional objects to use 8-way vector operations, just enough independent operations. If you have more than one 4-element vectors (like a position for each part in your rocket) you can work on two items at once. Heck, a 4x4 matrix operation already has multiple independent row-column dot products to handle. To best use FMA instructions you might even turn the whole calculation on it's side and pack each vector register with just one number from eight separate objects. Point is, just about any code doing lots of math can be optimized to make good use of vector instructions. When you do use vector instructions, processors since at least Pentium 4 and Athlon have at least twice the throughout in single precision (the single precision instructions may not be much "faster", but twice as many single precision numbers fit in a register).

[dueb]

I really hope that the devs are keeping an eye on this thread.
So much interesting stuff here! ;)

[Hannu]

[quote name='Johould']To best use FMA instructions you might even turn the whole calculation on it's side and pack each vector register with just one number from eight separate objects. Point is, just about any code doing lots of math can be optimized to make good use of vector instructions.[/Quote]

This kind of tricks are possible, but my point is that they need almost always (in practical situations) some special conditions to be effective. They do not work with any code or any problem. We can pack calculation of several objects if there are no conditional jumps, no transcendential functions (except sqrt) and no interactions between objects. Suck packing requires arranging of the data in memory (or registers). If there are not long enough calculation sequences it decreases benefits. Typically most time taking calculations in mechanical simulations are interactions between objects. They have many comparing and conditional jumps (if vertices are close enough etc.), objects can need different handling, etc. In practice only very few problems can utilize vector instructions maximally. Especially possibility to calculate 8 operation simultaneously instead of 4.

[radonek]

[quote name='*Aqua*']I sometimes wonder how a KSP 2 with the [URL="https://www.youtube.com/watch?v=fO7XhaTGDYg"]engine[/URL] from Infinity Battlescape would feel like. Imagine, no more scene switching, no need for a scaled down solar system, no trouble with floats, nicer graphics and probably no problem to have several solar systems you can go to, Newtonian physics already included, procedual generation of nearly everything which allows for billions of different star systems, planets and moons. Also rings with asteroids in it. <3[/QUOTE]

Thats an easy one: you'll end up with something akin to Space Engineeers. They don't have trouble with floats - because everything is in fixed coordinates. They have infinite space - but no celestial mechanics. Beautifull procedural planets, but no orbital physics - you deorbit by aiming nose down (?) and accelerating (!) unit you hit grav well. The have newtonian "physics" that works great for going around stationary objects, but falls apart horribly at incredibly "high" relative speed of 100m/s. They have asteroids (read: imovable rocks) but no moons because that need orbital mechanics again. In short, it looks great but comes nowhere near KSP in terms of "space" physics.

[Korizan]

I do have to wonder.
If every part is treated as an individual ship, then you could have 1,000 one part ships, or one 1,000 part ship, the result is the same.
Which leads me the the question of does Unity 5 allow the merging of parts or at the ability dump calculations as they are not needed.
Example. Aerodynamics - a required calculation while in a atmosphere but does the game continue to do the calculation even though the ship is in space ?
IF there is the ability to skip or use conditional calculations then you could speed things up considerably.
Or the bane of most games is collisions, simply removing those calculations for connected parts could have a drastic effect on performance
However it sounds like Unity V does not allow for this, but rather optimizes (for lack of a better word) the use of current resources which will give you a gain but not on a grand scale.
Small ships will see small gains and large ships should see the most gain but I doubt it will be overwhelming.
I think the biggest change will be in memory which should remove a lot of crashes and lack of memory effects.
Up to now the graphics have been a non issue, or should I say very few if anyone has felt the effects of a graphic card lag.
However as the graphics are improved it will become a question of is it the CPU or GPU or both that are causing the problem.

If history has anything to say, then as soon as KSP gets the game to run 1,000 parts smoothly people will try and run 2,000. Edited November 26, 2015 by Korizan

[Red Iron Crown]

[quote name='Korizan']I do have to wonder.
If every part is treated as an individual ship, then you could have 1,000 one part ships, or one 1,000 part ship, the result is the same.[/quote]
It's most decidedly not the same. Each motion of a part affects those attached to it, while separate parts only interact when colliding. So the thousand part ship is not easily threadable because of interdependencies of the calculations, while the thousand one-part ships are almost always independent and thus easily threadable.

[quote]Which leads me the the question of does Unity 5 allow the merging of parts or at the ability dump calculations as they are not needed.
Example. Aerodynamics - a required calculation while in a atmosphere but does the game continue to do the calculation even though the ship is in space ?
IF there is the ability to skip or use conditional calculations then you could speed things up considerably.
Or the bane of most games is collisions, simply removing those calculations for connected parts could have a drastic effect on performance[/quote]
AFAIK no aero calculations are performed when outside an atmosphere (aside from checking for if there [i]is[/i] an atmosphere). Parts one the same ship already don't collide, their only interaction is the constrained joint where they connect.

[quote]If history has anything to say, then as soon as KSP gets the game to run 1,000 parts smoothly people will try and run 2,000.[/QUOTE]
I could not agree more. It's the KSP variant of [URL="https://en.wikipedia.org/wiki/Parkinson's_law"]Parkinson's Law[/URL]: Part count expands to consume available performance.

[radonek]

[quote name='Red Iron Crown']I could not agree more. It's the KSP variant of [URL="https://en.wikipedia.org/wiki/Parkinson's_law"]Parkinson's Law[/URL]: Part count expands to consume available performance.[/QUOTE]

Don't forget Whackjobs Addendum: "…and then some more" :-)

[More Boosters]

Finally you Windows plebs will be able to run 64. Maybe you'll even not have krakens!

Ubuntu doesn't play around, when I get a Kraken it's the entire planet I'm on that gets removed. :confused:

[numerobis]

Another fun quadratic-time hit is detaching a lot of parts. I never stepped through to understand that one.

Resource flow could be definitely be switched to a faster algorithm, though it would break a lot of mods.

But as Daid mentioned, if you try to analyze performance without profiling, you're just bulls hitting yourself.

[COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR]

"Bulls hitting" is the best DYAC I've had all month.

[kiwi1960]

What I read here (page one only, I stopped after that...) is a non Squad person asking a question, and non squad people answering with their opinions!

Hence, its a waste of time reading unless a Squadie answered... and I'm sorry if they did, but I was unwilling to read multiple pages of peoples opinions when, to be kind, its only opinions and they really have no idea.

But, I'll add my opinion to the mix.

I do not care!

Why? Because the game we get will be the game we get, I imagine some will be over the Moon... err... Mun and VERY happy, the majority will be unhappy and will continue to moan like they always do forever and a day!!!!

BUT... IMHO .. the game will be like most major version updates... there will be bugs, lots of them... and this will result in even more complaints... and at least one, but probably many more, minor version updates till at least half of the people are happy... as is always the case...

whatever will be, will be.... que sera sera!!!!

but it seems many ..... hmmm, let me put this nicely... please, don;t be offended, it just looks this way to me right now...

Before a major update... people speculate and moan.. they then moan and speculate... when released, they moan.... those that are happy usually take longer to moan... but moan they do...

Either about the game, or like me, about the people doing the moaning...

like now... or.. maybe moaning is a very harsh word... they SPECULATE without the benefit of information... they speculate from .... a desire of what the game should be like... to them... that always leads to disappointment!

My advice.... stop speculating and just be patient and wait... you will get plenty of opportunity to either love it or hate it once its released.

FYI.... I came here today to see if anyone had posted on a major bug I came across... well, not a bug.... but every now and then, the game freezes for a second or so and its really really really REALLY annoying.... I know peolple have posted about it, have noticed it... but I'm not expecting a fix... I never do.

I'm 55.5 and I stopped expecting miracles many many years ago!

But I live in hope.... but I refuse to moan or complain about it... what is the point? I get the feeling some are so young that they expect everything to be perfect as if they live in some Utopian world...

If there is a fix... good, if not, too bad.... and I draw the line at moaning (speculating) about FUTURE updates... as if anything said would result in a better update? It won't!

It will just get your hopes up so high only to result in a future disappointment for those engaging in the speculation.

Be happy.... with what you have and what you get.

I'm hoping Santa brings me a Rolls Royce with a diamond studded dashboard... but I know it won't ever happen... its nice to dream though... just be real about , people. BE REAL about it. :)

[Kobymaru]

[quote name='Red Iron Crown']I could not agree more. It's the KSP variant of [URL="https://en.wikipedia.org/wiki/Parkinson's_law"]Parkinson's Law[/URL]: Part count expands to consume available performance.[/QUOTE]
Well, is that a bad thing? This shouldn't be a reason to not improve the part count. I think that people have twice as many parts available, they can do twice as awesome things. (Or 4x? or 1.414x? Or 7.389x? I don't really know how awesomeness scales)

[Claw]

[quote name='Kobymaru']Well, is that a bad thing?[/QUOTE]

I don't think they mean to say it's a bad thing. Just to say what the potential next complaint will be. I'm not sure if there's a part limit that could be reached that wouldn't upset someone. And if that ever did happen, the next complain would be that the unlimited part count was limited by the 5km physics bubble.

[Hannu2]

On 26.11.2015 klo, Red Iron Crown said:

[quote name='Korizan']I do have to wonder.
If every part is treated as an individual ship, then you could have 1,000 one part ships, or one 1,000 part ship, the result is the same.
It's most decidedly not the same. Each motion of a part affects those attached to it, while separate parts only interact when colliding. So the thousand part ship is not easily threadable because of interdependencies of the calculations, while the thousand one-part ships are almost always independent and thus easily threadable.

If you have 1000 separate ships you should calculate interactions between them. It would be more complicated than calculating one 1000 part ship. In both cases you have to calculate motions of every parts. Connections are just assumptions of interactions between bodies from physical point of view. If parts are connected joint is modeled with simple spring type joint and there is no need for complicated collision detection. Detection of collisions is at least as hard to parallelize than calculation of forces between connected parts.

 

Quote

I could not agree more. It's the KSP variant of

Parkinson's Law

: Part count expands to consume available performance.

Of course. But it would be more fun. You could deny almost all development in world with that argument.

I think that there would also be a limit. Probably most people would not make massive constructions of tens of thousands of parts even if it would be possible. Most people would begin to want more action stuff instead of insane engineering monuments.

Edited December 2, 2015 by Hannu2
I need practice in the new quoting system

[Red Iron Crown]

13 hours ago, Hannu2 said:

If you have 1000 separate ships you should calculate interactions between them. It would be more complicated than calculating one 1000 part ship. In both cases you have to calculate motions of every parts. Connections are just assumptions of interactions between bodies from physical point of view. If parts are connected joint is modeled with simple spring type joint and there is no need for complicated collision detection. Detection of collisions is at least as hard to parallelize than calculation of forces between connected parts.

Sorry, but this is just incorrect. Independent bodies with collisions is close to embarrassingly parallel, while bodies joined by constrained (or even unconstrained) joints require calculations depending on the results of calculations for other parts, much more difficult to thread. Have a look at the benchmarks here, Scene 5 is closest to a single KSP vessel and shows marginal improvement from additional threads, while those with multiple independent bodies show more marked improvements from additional threads.

My observation about part count was more tongue in cheek than anything, but it's not wrong to observe that just about any mission in KSP can be done with a few hundred parts at most. I get that people want to build higher part count things for a variety of reasons, and I'm certainly not suggesting that performance improvements are undesirable.

[sal_vager]

This really should have been in Dev discussion for a while now, moved.

[panzer1b]

From my experience one of the major issues is resource calls.  For example, i have a capital ship that is ~250 parts, it uses 3 nukes and ~10 fuel tanks for propulsion systems.  I have a very similar ship, that is also 250 parts, but it uses ion engines.  That ship, despite being the exact same (+-10 parts from other one) part count, is like twice as laggy since im guessing around 50 engines and who knows how many batteries+ion tanks makes the resource system (which is in my opinion horridly unoptimized) go insane.  Im no expert in programming, but from what ive heard, 10-20 calls per frame is a little overkill is it not?  I would personally be more then happy with say a +-2 or so dV error in the range a ship can get, then this much lagfest because of resources being terribly unoptimized.

 

The new aero/heat is also not helping, as it seems that every subsequent update increases the lag considerably (especially in atmo, before i could launch a 1000 part ship+launch stage, now i cant even dream of that, 500 part launcher is already lag city).

 

Finally, im just hoping that 1.1 at the minimum lets me load ~4 300 part ships in the same spot without it becoming painful.  I tend to avoid having excessive part counts on a single ship, so even if the physics doesnt multi-core on one vessel, it doesnt matter that much as i enjoy multiple vessels in teh same spot all shooting each other compared to a single super massive ship (i tend to relegate such things to purely cinematic useage, and i dont care if framerate is 2FPS when all imn doing is a screenshot or similar thing).  Id be glad with a 30% increase to single part ships, and a considerable improvement with lots of small vessels all together.

[Cdr_Zeta]

Not getting lost here...please tell me KSP 1.1 will work with Unity 5 and 32bit KSP.

I will be looking at Unity 5; but no intention of using Win64 KSP.

Zeta

[Eric S]

12 hours ago, Cdr_Zeta said:

Not getting lost here...please tell me KSP 1.1 will work with Unity 5 and 32bit KSP.

I will be looking at Unity 5; but no intention of using Win64 KSP.

Zeta

 

It will.  At most, there will be an option to use Win64, not a requirement to do so.

 

[includao]

I just want to the part count to increase a little bit. Currently, it is very hard to have 2-3 ships with 150-200~ at the same spot.