Eric S

The microbenchmark for non-threaded connected rigidbody physics simulations shows about a 50% improvement in most cases, seldom more, and sometimes less. As I understand the biggest problem with part count scaling (resources), the algorithm used is o(n^2), so a 50% increase in parts would result in 1.5*1.5 (or 2.25) times as much computation required. A doubling in parts would result in four times as much computation required, resulting in a quarter of the display rate if you were computationally bound to begin with, looking at just the resource utilization code. On the more optimistic side, the most KSP-like Unity 5 game I'm aware of, Besiege (think KSP but making medieval siege machines) had some rather significant performance improvements in their Unity 5 update which just came out Friday. Now, Besiege doesn't have the resource tracking issues that KSP does, but they are seeing 3x simulation framerate improvements even in times when multithreading shouldn't have been a big win (still a minor improvement from multithreading because Besiege almost never has a single collection of parts loaded, since there has to be a target). Then again, the demo the devs showed with that much improvement could have come from the improved collision detection, which I don't think is that big a deal in KSP. Basically, there's a lot of things changing under the hood which could improve same-craft performance in switching to Unity 5, but without having code profiling statistics for the current version of KSP, it's hard to predict how much these improvements will improve the overall end result. Having one part of the code running 4 times faster doesn't help much if that code is only running 5% of the time and the other 95% of the time it's running code that hasn't improved. Having one part of the code running 50% faster doesn't mean an overall 50% increase in speed unless either some other code has been improved even more or ALL the code is running 50% faster. Personally, I don't think we're going to see a huge increase in usable part counts on crafts until the scaling of the resource allocation code is improved, either by caching the results (which the devs have discussed) or by finding a "better" algorithm. Or better yet, both, because an order(n^2) algorithm is still an order(n^2) algorithm after caching is added, it's just a much faster order(n^2) algorithm. Then again, arguing worst-case conditions may not be the best approach when discussing KSP since it's possible for something that behaves "better" in an absolute worst case scenario to be slower during any conditions where the game would actually be playable. With all that said, my prediction matches cantab's prediction. I don't think it's impossible that the actual results will be outside that range (in either direction), just unlikely. If I had to do an over/under on that prediction, I'd probably hem and haw and never give an actual over/under, since the pessimist in me thinks it's more likely to be under 20% than over 50%, but the kid in me looks at the Besiege improvement and goes "ZOOMMMM!!"

The 64-bit changes are strictly a matter of usable memory space, the accuracy won't change between 32-bit and 64-bit, since the 32-bit code is already capable of using variables larger than 32 bits. On the other hand, it's possible that this issue may get improved by general code cleanup/debugging in PhysX, Unity 5, or the KSP client itself.

Simple: Unity 4 64-bit wasn't stable enough (the community hack works for many people, but not everyone), and Unity 5 wasn't released until 1.0 was half way through it's dev cycle. Even if they had decided to switch over to the beta version of Unity 5, it wouldn't have reduced the amount of work needed, which means that we'd still be waiting for 1.0. While that may be fine for some people, I suspect that the contracts for working on porting KSP to the various consoles probably had something to do with them needing to have something to call 1.0 sooner than some unknown time in the future.

That's because Windows has the habit of switching a running program between CPU cores, so instead of one 100% maxed out core, it looks like 4 25% utilitized cores, unless you're looking at much more detailed information. Also, on the Unity 1.1 comment, we have reason to believe that a single craft will still be simulated in a single thread. The only people I've seen simulating multiple connected rigid bodies (the type of simulation KSP uses) have been research projects, not commercially available toolkits.

I'm pretty sure that I've read somewhere that they're aiming 1.1 at 64 bit for all current platforms.

There are caveats, but Unity does support on demand loading and unloading of assets. http://docs.unity3d.com/ScriptReference/AssetBundle.html As for the main topic, Maxmaps suggested that 64-bit addressing on all platforms might open up the possibility for more stock planets during one of the Squadcasts, but it was only a discussion of the possibility and his personal interest, nothing like "We're all excited about the possibility of more planets, YAY!"

Claw is right, the 64-bit addressing space isn't represented in the save file in any way, so that won't be the cause of problems. If I had to guess, I'd say that wheels would be the most likely cause of save-game incompatibility since they're getting reimplemented. That said, Maxmaps said that while they're not certain, save compatibility is looking good for 1.1.

Specifically, the Unity 3D editor is now available for Linux.

This. From what I've seen, there's all of one general purpose physics library available that will do connected rigid body physics simulation on GPUs. I'm not even sure KSP would benefit from that, since GPUs are basically designed for highly parallelized work, and connected rigid body physics aren't currently easy to work in parallel, and there are other issues as well, from what I've heard.

Well, from a purely code-optimization point of view (without algorithm changes), 50% isn't that modest, and that's what the connected rigid body microbenchmarks are showing (unless I misread them). Not saying I expect to see a 50% overall improvement, but it's within the realm of possibilities. I do think that they'll need to optimize the resource algorithms in order for us to see that kind of improvement, though.

I'm hoping to have been wrong as well, I'm just not certain that this isn't the case of a non-programmer (Maxmaps) getting something wrong when talking about something technical.

They showed a 2.5m jet engine during the squadcast, so you might get at least some of your wish. Actually, one of the modders they brought in is working on at least some optimizations. Not dedicated to it, however. Trying to find a reference to that comment.

No, the 64-bit stuff being discussed almost strictly affects addressing space (amount of usable memory for the most part).

And I was just justifying the original statement, which is more in tune with the way I see this unfolding. What you see as a snails pace I see as faster than any other Unity-based game that uses the same feature sets to the same degree as KSP. Not cranky, I just have a different point of view.

That puts the full release out when the 1.0 development cycle was at or past the half way mark, and I don't blame anyone for not planning around release candidate software. A place I used to work for got screwed once doing that just to have a "minor" bug fix at the last minute change the API enough and just in the wrong way to cause serious delays in one of our projects. And yes, there are testimonials talking about porting programs from U4 to U5 in an afternoon, but none of those are about programs that make much use of PhysX. PhysX is probably the most major Unity component that isn't backwards compatible between U5 and U4. Not the fault of the Unity devs, PhysX 3 isn't backwards compatible with PhysX 2, and even that incompatibility was necessary in order to allow better software optimization. Honestly, of the Unity-based games I'm playing that use PhysX heavily, it looks like KSP is going to be the first one to release an update based on U5. Simply put, 1.1 is the first non-patch version of KSP that had it's development cycle start after the Unity 5 release, so yes, this is a prompt upgrade.

To be more specific, it's a restriction in the PhysX framework itself, though you can't get too upset with the PhysX devs. None of the competing physics simulation toolkits that I'm aware of allow a single group of connected rigid-bodies to be spread across multiple threads. That's currently only happening at the research level.

Not at this time. Unity doesn't currently support non-CPU physics calculation at all, and the only GPU acceleration they're working on in for hair and cloth from what I've heard. For that matter, I'm not even certain that we'd gain anything from GPU acceleration of physics calculations in KSP even if it were possible, because the connected rigid body physics simulation that KSP uses hasn't been parallelized outside of research projects and I don't think most GPUs would beat CPUs for workloads that can't be parallelized.

Doesn't change what the actual point is, that the player is getting more tools to make the game easier as they progress, rather than having the game get harder. I'm not sure I agree with that analysis, though I have thought it felt that way at times myself.

Can cause problems, doesn't always. Which is enough of a reason to me to oppose this, unless they can change something so that it doesn't cause problems. The rest of the suggestion is good to me.

Not obsessed with them, just noting what's referred to as a violation of the principle of least astonishment. It's a trivial thing, but it doesn't change the fact that i disagree with it. It won't bother me if they do release it as 1.0.5, it's just not the decision I would have made.

The only crossfeed "bug" I know of involves the one-connector side of the tricoupler not being able to pull fuel from any of the three connectors on the three-side. It's not a bug, it's a design decision that some people may not agree with, and I'm fairly confident that it's not the problem here. I've created a similar craft to test this kind of fuel feed, and it works fine for me in the most basic case (mk 1 capsule, fuel tank, tricoupler, docking port, docking port, stabilizer, Nerve). So either you've found a corner case in the fuel flow code, you accidentally turned off fuel flow somewhere, or I failed to recreate the issue properly. Did you dock the engines in the VAB, or after launch (and if in the VAB, why have them, out of curiosity?).

Agreed. It's been my general expectation in X.Y.Z versioning that changes in Z shouldn't break API compatibility. In fact, OS dynamic linkers in some OS assume that to be the case, and if a program asks for version X.Y.Z of a dynamic library and X.Y.(Z+1) is available, then that higher version is what the runtime gets linked against. This means that any non-backwards compatible changes require incrementing X or Y. Given that Unity 5 will break any mods that include wheels at the very least, I don't think 1.0.5 would be an appropriate version number.

It's not currently possible, but it might be later (when they add multiplayer?). Right now, the game only has one physics bubble, and it's limited in size (FP rounding errors cause issues when you go past about 25-30km from the center of the physics bubble). Depending on how they code the multiplayer support, multiple physics bubbles may be possible, but it isn't required.

Duna's got a bit more atmosphere in 1.0 than it did in 0.9, try a higher altitude. I can think of a few reasons Trajectories might make the wrong projection. You've updated Trajectories, right? The other thing that's possible is that Trajectories assumes a certain angle of attack, and if you didn't aerobrake the way it expected you to, the atmospheric drag would be different.

The PhysX stuff is the major component that changed in a way that isn't backwards compatible, but not the only one to do so. Games that don't use PhysX much are fairly easy to port over (some devs have claimed porting as fast as an afternoon), but I haven't seen any game that made major use of PhysX where the port went quickly. It might have still gone faster than expected.