More object nesting in active scenes, Object consolidation. And krakensbane.

[AdmiralTigerclaw]

I'll start with the simple disclaimer that I'm not familiar with the Unity engine, but I have worked with a situation I'm about to describe before.

Anyway, recently I was encountering a slowdown in my gameplay with some mods. Naturally, mods aren't a concern to the devs because they have bigger fish to fry than third-party work, but for many of us, 90% of the game is built on our massive stacks of mod folders.

But I digress before I begin:

In the process of hunting down the offender, I discovered the krakensbane API code. A clever piece of code that essentially turns the player vessel into Futurama. (You guys got Prof. Farnsworth on the team there at Squad? I suggest whoever wrote that code gets a Farnsworth avatar and puts 'great news everyone' in his title. Just for laughs.)

With a little further testing, I discovered that the problem was what a mod was doing, and how krakensbane works. In this case, krakensbane decides that after a certain distance (or in this case, velocity), that instead of moving the ship around the universe, it moves the universe around the ship to keep things stable in the floating point values. That means that instead of an unstable, potentially explody ship, the code grabs the rest of the universe and proceeds to perform more or less a SETPOS (set position) command on it.

I have LITERALLY dealt with in-game scripting using a method similar to this. It does NOT scale well. In fact, it scales HORRIBLY.

The game was X-2: the Threat, and I was assisting with creating a script that simulated a point to point traveling hyperdrive effect. ('Freejump' scripts.) The code worked by using a math algorithm the coder wrote up to draw a line between the origin of the ship, and a destination selected on the map, then applying SETPOS command along the length of this line at a high rate to simulate the 'effect' of rapid transit without some kind of instant jump.

It worked. It was fun to use. And it worked well...

Until I stress tested it with an M1 carrier disgorging thirty M3 Split Mamba fighters, all programmed with intercept commands, autojump software, and freejump. The moment they detected a target and the automatic intercept scripting kicked in... Well, after the first three vectored onto target and jumped, it became a slideshow. By the time all thirty were in jump, the PC (of the time) was crying superheated air through the vents. The scripting worked wonderfully... Provided you didn't attempt to scale up what you were doing to anything resembling mass tactical maneuvers.

And this brings me back to krakensbane. Clever code, but in solving one thing, it's introducing a whole new problem. That problem is that if the rest of the universe has very much added to it in the form of other objects or parts, then the universe position/momentum resets are very quickly going to increase the number of operations to be done. The mod I was using that made this problem show up was simply adding static objects all over Kerbin via kerbtown. However, in adding those objects, krakensbane is given more and more objects it needs to grab ahold of and move. I'm uncertain as to the exact object count, but it couldn't have exceeded two dozen at the most. Either way, the results are clear. I have my physics frame ratio set up to overdrive values, and it went from just shy of 1/1 realtime gameplay ratio, to 2/5ths (.4) the moment krakensbane kicked in.

Overall, the bottleneck is, and has been the physics engine. Or more in my experience, the scaling of it. In the last... two years of gameplay I have attempted a number of ambitious space projects within the game only to be met with one game-halting limitation or another. Either the physics engine suddenly goes glassy-eyed and I can't even quit out of active gameplay to KSC because the buttons don't work, or the gameplay slows down to such a crawl that the time rescale factor leaves me thinking I've discovered a white hole in the vicinity of kerbin. I've tried to make a large station (twice), a moonbase drilling operation (twice again), and building the orbital infrastructure for a vast communications array. Each and every time, I get my infrastructures into the adolescent stages and start bringing things up to speed, when I encounter a problem that seems to stem from scaling issues. The physics engine stops responding. (Only seems to happen when its strained), parts spontaneously develop new metamaterial characteristics (I had a docking ring that behaved as if its center mass was half a kilometer away, and the camera was half a kilometer the opposite direction), or the game just starts playing so slowly that you can't really do anything.

All because it seems that the engine just can't SCALE. And with either a universe full of active 'missions' (satellites, probes, vehicles, bases), or a high part-count vessel, it just seems like even with on-the rails physics and other such work, it can't handle the busy universe of an advanced space program.

So I'd like to put some thoughts into this. Can the physics engine be throttled? Can objects undergoing negligible change be ignored for short times? Can priority be assigned and cycles freed up? How can the game scale better?

Again, I disclaim that I don't know Unity. And beyond a hobby-gamer's knowledge, I don't plane to get to know unity. But I will give my thoughts.

My thoughts on potential ways to solve problems that are more scale friendly:

1: 'Warp Bubble'.

Krakensbane scales poorly because it takes the rest of the scene and moves it around the ship. Which is fine when the scenes are still mostly empty voids, but terrible if you want to take it further. It does its job to keep the ship in the middle of the scene so that values are kept safely low. However, the more you add to the scene, the more load you put on this one task. Why not instead of placing the ship at the center of the scene and moving everything else around it, place the ship into a nested 'scene within the scene', like a warp bubble. The ship itself has a meta identity independent of its parts. Define an area around the vessel's geometry as a fixed space it orients and rotates in, and then place that bubble into the universe as an object. The ship maintains position 0,0 inside this bubble and all physics work as normal. Meanwhile, the bubble itself moves about without having to pick up and move the universe except when hitting harder boundaries. (Like when the deep space krakensbane needs to be applied.) Reducing the number of constant events that needs to take place. In a way, it's like a warp bubble.

2: Single-object physics consolidation. Dynamic switch to 'simulated-single-part'.

Every part on an active vessel is given a physics pass. This scales so poorly that its generated a mod to help... If you like to stop the game and start it back up every five minutes. But does every part in a vessel need to constantly have physics passes on it in a zero-G freefall environment? I'd suggest a mechanic of some kind that takes a look at a part set, and every Nth pass, decides 'do I see non-negligable changes in forces between the connected parts?' And if the answer is 'no', gather up the parts, consolidate the sum of all their force values into one unit, and apply it universally for the vessel until it encounters some kind of non-universal change.

Base example of this: A space station in high orbit. The code would make a pass through its values for each part and determine nothing is changing enough to warrant bothering with making constant physics passes on everything, then pack them all away and just perform calculations of forces acting on it as a single point at its center of mass. A mode it only breaks out of when it encounters a player input (if it's the active), or an external force. (such as a collision) At which point it goes 'okay, not expected', and pulls all part values out, identifies what forces went where in the normal all-parts physics model, and goes about business as usual until things settle down again.

3: Kraken Schmidt!

And of course, one last thing that might be easier to tweak in the short term. Does krakensbane need to run on EVERY physics pass? IoW: Does the universal SETPOS command need to be run hundreds of times a second? Coming from an electronics engineering background, this is like having an industrial control system that is tasked with reading a sensor for a fluid level in a tank, and switching pumps on and off to keep the level steady. If the system operates directly with the sensor to trip the pump, then when the fluid goes level with the sensor, the small ripples and slight shifts in level are going to cause it to trip on and off as fast as the clock cycle can let the readings pass, causing the controller to trip the pump switches on and off at clock speed... This would burn out the pumps and consumes enormous amounts of processing power. So the configuration often used is our good friend the Schmidt Trigger. Where only after going above a certain limit do the pumps trip and stay on until lower threshold is passed. This is known as the 'dead zone'.

If the velocity threshold for Krakensbane is 750 m/s, and then it zeroes the ship velocity in the scene and begins simulating by moving everything else. Then instead of running a setpos command every cycle from this point onwards, the ship should be allowed to move a limited distance and increase velocity a fixed amount again before the next 'step' occurs. Which would effectively spread the movements of the universe around the ship out a little easing the cycle usage up substantially.

Those are my thoughts. Make of them what you can or will. If they're of no use, *shrug* that's fine. If they are of use, cool.

[Javster]

What is krakensbane? I still don't quite get it.

[Red Iron Crown]

What is krakensbane? I still don't quite get it.

It's the technique used to tame the deep space Kraken. Before it was implemented, all coordinates in KSP were given in reference from the body a ship was orbiting; this was sufficient when tooling around in Kerbin's SOI but when orbiting Kerbol there wasn't enough precision in such long distances, so parts would flutter and the ship would shake apart.

The krakensbane solution was to make the ship the origin of the coordinate system, so the distances to the parts of the ship had sufficient precision, even in deep space, to avoid kraken effects. The tradeoff is that the orbital calculations become more difficult to implement and debug (the center of the SOI is the simplest origin, calculation-wise).

As for the OP's suggestions, it's too bad that it doesn't seem to be getting much response. I don't really have the programming background to give it much useful feedback but it seems reasonable from my layman's perspective. Hopefully some of the programmer types around here can provide some more useful comments.

[Sky_walker]

They didn't implement a Schmidt Trigger on the physics engine? O_o And I always thought that full calculations on every object in the frame are only done for a demonstration purpose while you always optimize stuff for a release-worthy version.... oh foolish me.

No, seriously though: if the physics pass is done on every object all the time then it qualifies as an obvious bug, cause someone screwed big time.

[Ruedii]

Object consolidation would greately reduce the kracken, but on most physics engines, nesting the point of origin would actually increase the kracken not decrease it, by creating two rounding errors instead of one, even if those two rounding errors are smaller.

However, when you have two ships in the physics, treating them as separate physics layers until they are close enough to colide, would in fact reduce the kracken.

[Sky_walker]

BTW: well done investigating Tigerclaw

[Ruedii]

As an additional note, "binding" objects to each other unless the forces between them exceed a certain point would also improve the performance and reduce the kracken.

[Vindelle_Sunveam]

THat is an excellent report. I am not the programmer and understood all of what you were going for (or at least, I feel I did). I hope this gets more attention.

[Vaporo]

1. In principle, this works great. However, this sounds like it would also cause a whole new set of bugs that need worked around. And collisions could be difficult to handle as well, as each vessel would have its own "warp bubble." Of course, you could create a single, master warp bubble for vessels that come close enough together, but planetary collisions still may be a problem.

2. Good idea, but maybe it would be better to implement "fake" not cpu-intensive physics for objects that have low movement, or apply a movement damper to low-force craft before putting them on rails. That way it doesn't end up causing very long structures that are being slightly bent, but still considered low-force, from magically being straightened at though you suddenly went into time warp. There are dozens of ways to get around that problem.

3. Really? I thought this was already implemented. I thought that Krakensbane was only applied every couple of seconds, and that's why we have bits of smoke that suddenly appear in front of craft while in the atmosphere: Krakensbane is moving the origin, which in turn caused the smoke to move. Still, you're the programmer. Maybe, instead of being on a timer, Krakensbane only applies every time the craft move a thousand kilometers, per se, from the previous origin.

[AdmiralTigerclaw]

Like I said, I don't know the unity engine. And I took a look at the blog, not any code. The blog explicitly stated in words 'every physics pass' and that immediately set up a red-flag for me when I was trying to hunt down and fix my mod problem. Once I tested the removal of the Kerbin Side mod (which was giving me more land bases), I gained massive improvement. I'd already ruled out various visual enhancements and rendering upgrades, and the only thing that mod does is add static objects and launch spawn-points. Most of these aren't rendering during the slowdown and none of the static objects have physics running on them (beyond whatever statics get). They're just... There.

I did a further test by removing Kerbin Side and going down to just base level Kerbtown to see if it was simply mod code. (I know Squad is not going to bother trying to troubleshoot or provide dead-end fixes for what could turn out to be faulty mod code). My results were that it ran smooth with kerbtown installed and still runs smooth with Kerbin City. However, Kerbin City is only two huge objects. Kerbin Side deployed a few dozen as the author of the mod distributed his base objects like one would the terrain objects of a FPS. (Individually)

So the testing came literally down to object count. Not geometry for renders, or any special code, or size, or anything. Just, the count.

Given the current status of KSP, I'm not surprised about the Krakensbane doesn't scale well. With only two bases on stock Kerbin, there's no way to really stress-test how demanding the Krakensbane code would be. But I'd like to think in my own head that such a finding is invaluable so they can start coming up with a new, better way to fix that issue. Right now I believe they're still working on the scope of the game, but at some point the scale/scalability will need improvement. And that means finding ways to cheat on the physics engine while making it still look like it's working in full. Krakensbane does that, but it does it in a messy manner.

[allmhuran]

If I recall correctly, Harvester gave a talk about the solution at GDC or some similar conference. In explaining the details he mentioned that the origin shifts in steps, not continuously, such that the shift only occurs when you come near to the edge of the envelope of accuracy around the vessel, not every frame.

[AdmiralTigerclaw]

I dunno... Emphasis bold.

Krakensbane is the same thing, only for velocities, instead of positions. If the vessel's velocity exceeds a max limit, Krakensbane zeroes out the vessel velocity, and "absorbs" it. Then, on every physics update, it moves the entire universe back, at the velocity it absorbed from the vessel. The end result is that after a certain speed is exceeded, the vessel becomes stationary, and the universe starts speeding in the opposite direction. This universal velocity is stored in a double-precision vector, which uses 64-bit values, so it's perfectly accurate up to insanely high values (way past c).

Then again, that IS old.

But there ARE two types of anti-kraken code though. He may have been mentioning the deep space kraken code at the conference. That code would be much easier to increment in steps, while this code doesn't seem like it has such a clean stepping solution. See, the krakensbane code here is being used to zero velocity so parts don't end up with varying velocity levels that tear themselves apart when rounding errors come through.

Once you zero the velocity and apply it to the rest of the universe, you have to move the rest of the universe on every update. Even if you only added increments of the velocity at every speed interval. Because even in steps, the universe has to keep moving in sync with realtime, or Bad Things happen.

That is to say, you zero your velocity 750 m/s and add it to the universe, the universe now moves at 750 m/s the other way. You add 500 m/s to the velocity of your vessel, the universe is STILL moving at 750 m/s one way while you move the other at 500 for the cumulative 1250. Either way, the universe has to be updated frame-by-frame. I don't see how steps could make it work without causing it to jitter by taking 'big' steps.

Edited July 7, 2014 by AdmiralTigerclaw

[vexx32]

I think that one mainly works because everything not the focused craft is pretty much on-rails unless it's really close to you. It's just changing numbers, and the planets are so damn huge and the distances so vast that a bit of jitter here and there is likely unnoticeable, if it occurs at all.

[GusTurbo]

This is all very well thought out. I'd be curious to hear a dev response.

[vexx32]

You'll probably be waiting until after the release of 0.24 before this receives any dev attention. Even then, it's not a given that they'll respond.