TheTom

Actually this would be my impression, too. As in: They finally got the development in a WAY more professional level, starting to fix stuff that should have been done ages ago (like efficient ressource distribution - the performance problem you could cause by adding 10 batteries was just not good). It seems that finally the development is (also) focusing on decent quality including not wasting all the performance you have through crappy code. They also go on a serious bug hunt AND fix obvious omissions in the API. If you look at it from what happens now - this is a LOT better than what was done a year ago. And I would not say it ends. KSP 1 maybe - but then there may be the time for some larger DLC or KSP2. My bet for the delay would be that they want(ed) to announce some release to experimental or so and things got delayed.

That is extremely true as a statement. It is quite likely they do a LOT of surplus drawing somewhere. We can hope THIS gets fixed in the Unity 5 release. I personally look forward to it - and have put KSP aside until then.

Wrong. Delusional wrong. FIrst, please find me a hard disc that delivers 400MB/S under even the best circumstances. None does - SSD regularly do. Heck, we talk of much higher speeds these days if you get a M2 interfaced one - much faster than SATA speeds. But even then, there are 2 issues you love to ignore: * SATA discs only deliver that for large files * and when not sharing access at all. If one of those two conditions is not met (like when loading a lot of small files) then HD speeds drop into the basement. I had a RAID of 8 Raptors (10k RPM discs) deliver an astonishing 10MB/second on large files - due to contention of access times. That is DESPITE a 1gb RAM cache on the dedicated RAID controller. Now 4 SSD allow me to copy files with 1GB/second on that Raid. And again, even under optimal conditions SSD are way short of the read speeds of a HD. Even of a SAS 15k RPM HD. And that includes reading one file only that is large and optimally organized on the disc. The moment you have multi access the head spends most time moving around. Which takes no time on SSD. This includes loading a lot of small files. Which incidentally is what happens in KSP. But there is NO scenario where the performance of a decent SSD is inferior of a HD. Including size. The biggest HD you can get right now is 10TB in 3.5" form factor. The biggest SSD is - in 2.5" form factor... 13TB. The big equalizer is still and has always been the price, with SSD being more expensive.

That is so true. Except it is not. Bug reports indicate that the physics calculation plays a smaller role. As can be seen on large rockets being a LOT easier on the computer in older builds. Sorry, the lie does not get reality when you repeat it a lot. Instead, the culprits are bad code. * UI to a small part * RESSOURCES for a large part. Tanks, everything that consumes and provides in game ressources. The ressource management loop has horrific code in it. Among other things it is regenerating lists of every provider on every tick. * Possibly also aerodynamics. Want a proof? Make a small ship. Then add 100 fuel cells. See the slideshow. Replace the 100 fuel cells with 100 resource neutral parts. Watch the difference. And given the identical part count for physics... that is not the issue. We can all hope that gets fixed for 1.1 or 1.2

Ok, so let me get into the what I would do game too. 1.1: Unity 5. That is a big thing due to a whole graphics update - and the UI is all graphics and pretty hodge podge in earlier versions by admission. Fix resource loading. 2.0: Quality Update.I name this 2.0 because it would be a really breaking change for mods - but one needed. Redo the whole backup to be parallel. Phyics: 1 thread per ship if possible by PhysX. Otherwise separate PhysX, Aerodynamics, Heat and Resources into separate threads (one per resource using a task mechanism and a thread pool). Redo the API to handle multiple passes (Reqest, Get calls for a ressouce) and introduce small delays - a multi pass Resource system could handle this a LOT more efficient than the current "every request loops all objects" approach. The idea: get THREADS used and decouple subsystems, allowing a craft to efficiently use 6-8 cores. This would break extensibility, but I think it would be worth it. 2.1: Integration. Start looking for standard mods that make sense. mechJep may be too much, but waht about little things like the automatic wakeup when approaching an interesting event (Kerbal Alarm Clock)? Minimum standard life support that does not kill people (USI life support). The mods are out there. STATION parts. Scaleable parts and replaceable textures - which can really cut down the number of parts and make them more manageable for a user. 2.2: Multi Screen & Complex Craft Support. Integrate a network interface for craft inforamtion and commands and separate programs to show a nice UI for those. Which would mean a second window (as separate program) showing me how my active craft works (fuel, heat) and having buttons. This nicely bypasses the "one window per Unity program" limitation. Work on a much better rocket management model - allowing a tree of stages (which means landers can "branch off" and be deactivated) and the definition of craft boundaries and payload (as in: Everything above this is a separate craft, inactive, do not use batteries etc. and activate when decouples). The current approach gets REALLY complicated when you have multiple landers etc. all folded into one staging sequence. The separate UI would also alloe me to have visual configurable buttons for things like lights, engines etc. 2.2: Graphics and Gameplay. Make nicer GFX - not talking about parts, I mean sky etc., and gameplay meaning a better run over the planets. More variety, Biomes etc. Some of this can come earlier, but here we talk about things like adding more moons etc. Colonization? Not sure. Then take it from there.

[quote name='*Aqua*']It doesn't matter that the calculations aren't that complex. Physics calculation is THE major resource hog in KSP. Everything else is pretty frugal compared to it. If it would be so easy to speed it up people would already have done it.[/QUOTE] That stupid statement is not more true if you repeat it 100 times. It is proven to be wrong. There are a lot of resource hogs. Even if you count the aerodynamics model into it (which can be replaced and is not part of the core physics loop) - it is not true. Resource allocation (i.e. in game resources) and graphics are proven resource hogs.Resources in particular are REALLY bad, creating potentially hundreds of memory allocations PER FRAME which are not only totally not needed, but on top also result in a lot of garbage collection by an outdated and sub par .NET implementation (the mono version used in Unity is ancient). Physics is not on the top of the list for anything but extremely small craft with very few resource consumers/producers (like a starter rocket: 1 engine, 1 tank, 1 controller). Once you hit larger elements the extremely inefficient code explodes. Now, Aeorodynamics is a problem, but then - most of the problem is seriously implementation, as can be seen in FAR (which does the calculations a lot more realistic AND not less efficient). So, stop spreading this lie. Physics can handle craft with 1000+ parts quite easily.

[quote name='NecroBones']lol, well, it's just that when you see the sun rise every morning, you start to expect that you can rely on it. Sadly, that's often the case in the software field. Lots of improvements/optimizations, or an architecture change (etc) often means 5% to 35% in my experience too (17 years IT experience). Every once in a while you get surprised and some brilliant new architecture might get you a 2x or 3x improvement, but that's exceedingly rare IMHO. Usually if you see those kinds of improvements, it's because the initial implementation was absolutely terrible from an efficiency standpoint. The thing is, what makes this less predictable is that the biggest bottleneck in the game (the physics) is being enhanced from a single-threaded to a multi-threaded architecture. So I wouldn't be surprised if we see a 50% increase in the number of parts you can put on a ship before your framerate drops to the same amount, but it's hard to say whether it'll reach (or exceed) that without knowing more. Some tasks lend themselves well to multithreading, and others only see modest improvement in performance.[/QUOTE] And again that ridiculous claim pops up. The biggest bottleneck in the game.... is not physics (as: physX) to start with. Ups. Here you logic goes. Despite claimed 17 years. And this is btw. also extremely simple to paralellize into a number of threads. How? Paralellize: PhysX (body motion), Aerodynamics calculation, Resources (one thread per resource), Heat. Introduce SMALL delays - for example calculate aerodynamics on frame behind. Noone will see the difference, suddenly you can use a lot more threads in parallel. Heck, I would even say you do not need to handle most resources every frame, to start with. Yes, the code in KSP is partially quite sub standard. Which puts it on par with a lot of cod I have seen. 2x-3x gains are not "exceedingly rare", I have seen quite a lot of them. A ton of code out there in companies is written quite badly thanks to "senior" developers with 5 years programming experience making design decisions. For example - you (like many) claim the problem is PhysX - but before some changes done to resource allocation and aerodynamics... one could launch much larger ships than today.

[quote name='Terwin']I would think that the aerodynamics change to start accounting for things like occlusion, lifting bodies, and general non-soup-like atmosphere would be considered a fairly substantial change. And while it may not be optimal, a first-pass coding of things like occlusion may not bother to check for the presence of an atmosphere before performing calculations, giving a slow-down both in and out of atmosphere for the sake of providing better atmospheric effects.(edit: almost forgot: occlusion is not just for atmospherics, it also affects solar exposure and other things) While I am hopeful for 1.1 to have a nice performance boost, performance optimization is not a simple task, especially with a substantial existing code-base and a rather avid fan-base.[/QUOTE] And again. aerodynamics are not handled in the physics code (i.e. PhysX) but in a separate replacable subsystem. THis is how FAR works. Among other things because this type of simulation is beyong what PhysX is handled to do. And in this particular case (aerodynamics) you ahve some seriously performance optimized code in FAR already.

[quote name='OrtwinS']That is quite a choice of wording. Can you link to the research? Sounds like an interesting read.[/QUOTE] Sure. [url]http://bugs.kerbalspaceprogram.com/issues/5136[/url] I personally found that when starting to try to launch career build satellites which had by force (The larger ones were not available yet) a lot of small batteries. To quote from the discussion there: [QUOTE]This is almost certainly caused (or at least made much worse) by inefficiencies in the Part.RequestResource function that is called on each fuel cell part each frame to add the electricity to the vessel. Each call loops through all the parts in the vessel building a list of all the EC storage parts (in a way that creates unnecessary garbage), works out which ones of them should get filled up and then splits the amount of EC being added between all those parts. So, in addition to the garbage thrash, this is effectively O(n^2) so as the number of parts increases the performance suffers drastically. [/QUOTE] Obviously this call (Part.RequestResource) is not limited to electricity. Which means any larger machinery (many tanks etc.) gets quite a lot of them in a VERY inefficient way. This means when going from 10 to 100 parts, you do not get 1/10th the performance but a LOT Worse. Which means optimizing this will give you a LOT more than "30%" performance gain for any "serious" craft (i.e. obviously not a 10 part micro satellite).

[quote name='KerbMav']Heat is calculated by itself and not as part of the physics engine, physics meaning the interaction of individual parts in the simulated environment and with each other.[/QUOTE] More exact: Phsyics - moving, movement powers between parts - is calculated by a Physics engine (PhysX) which is part of Unity. This is what decides the wobble, for example. Heat calculations (as well as the whole aerodynamics calculation) is done in separate code written in C# and part of the KSP codebase.

[quote name='Daid']General rule of optimization, do not expect magic. 5% to 30% is a rule of thumb (I'm an software engineer, 10 years of experience)[/QUOTE] Thanks for demonstrating the sad state of software engineers. Given the demonstrated and proven ridiculous bad code, anything below a 100% to 200% improvement would be a shame or something waiting for a lot more optimizations. The later would be quite acceptable given the brutal amount of rework that has to go into 1.1 due to the UI rework. Now, befor you guys come out and scream that this is ridiculous - it is NOT physics. Physics as it is can handle a LOT more than we can do today. Anyone with not 10 years software experience but 2 years KSP experience will remember how we could run multiple times the current part count in the past. Physics has not changed a lot during these times. What makes KSP slow are: * The non-physics simulations (heat mostly) * The user interface code (which is reworked) which supposedly was doing a lot of stuff in every frame, while the new UI creates / manipulates game objects and is drawn in the unity engine. * The resource allocation code. This means came resources (fuel, electricity) which is demonstrated to be extremely badly coded and gets significantly slower the more consumers/producers exist. THe main culprit here is the permanent allocation of new memory resulting in ridiculous amount of garbage collection. If all that is fixed to some degree, and multiple cores are used (for example it is not that hard to move the heat calculations to a separate processor) we should see a lot more than a 30% increase in performance in anything except trivial craft. Once you get into the 100+ part count the current code is a demonstration of wasted CPU cycles. Especially the resource allocation code really is slowing things down a lot. Well, heat too.

Yes it could. NOTHING would significantly change though. Because it is not physics that is slow - it is the UI and it is the resource allocation which is constantly searching ALL parts to find out where to get resources from. Not talking about CPU but in game resources, mostly electricity. The more parts you have the worse it gets, and it gets bad EXTREMELY fast. Also because it really abuses the memory allocation forcing constant garbage collections. So, no, it is NOT (only and mostly not) the physics thread. There is a bug report on that. Make a small drone (no need it can fly). Then add 70 fuel cells to it. See the whole performance crash and burn when you turn them on and off. This is why you should use large batteries etc. all the time - many small parts are extremely taxing in the processing loop, even if ignored by physics.

There are 2 issues with your statement. Nothing big - just totally invalidating it. * We KNOW that the UI is issuing a ton of draw calls. That is the lack of UI mechanisms to make it easier - which the new UI will fix. Especially with a lot of multi threaded work going into Unity 5.2 to combine the draw calls in a separate thread or something like that. But the current UI is quite ineffective. * Dx 12 helps all graphics cards. It kills a LOT of overhead in the driver section. I read in various places about a 20% gain even for old games that are not rewritten And most graphics cards support Dx 12 - or they could not run Windows 10 at all. They do not support the new features, but they support the new driver model with less overhead.

Hint: it is not. It is the UI and - the resource system (for in game resources). And that could easily be split into separate threads with a different API. It is inefficient as hell and it is single threaded. What about having all components register their demants and supplies, then resolve them for each resource separately Or, even better, so run the resource allocation in well written code (which it is not) separately WHILE the physics is looping. Yes, you may not get a 6 core machine utilized, but you would use a lot more than one core. Separate the calculation of the heat (another large subsystem) and the drag into separate threads, all running at the same time, then re-synchronize. And not all the calculations MUST run every frame.... heat for example can easily be done a LITTLE slower (every second frame), giving time to handle some other things in every other thread (like calculating things like the efficiency of solar panels). But there are quite a lot of separate subsystems doing time consuming tasks in KSP that can be done in parallel. Everyone assumes it is physx being slow - it is not, which is prooven by bug reports and measurements. And the history - once upon a time - on the same unity version - physics supposedly was running a lot faster. I could launch 300-400 part rockets, now I get a slideshow. Nothing in physics has changed. But resources was rewritten (bug report about the tremendous impact of bad code earlier in the thread), heat is a lot more complex now and the whole aerodynamics is not for free either. Seeking items to parallelism is not trivial, particularly when you have to deal with cardinality requirements. But it is mostly doable. By recutting the problem. In case of KSP I could easily split that quite a lot.