Rotation Vectors

[Burninate]

Wouldn't these be trivial to store, when a craft with SAS off unloads or fast forwards, and either load using modulo arithmetic on reload, or allow to continue simply rotating in unpowered-warp where momentum isn't calculated?

It doesn't add *much* to the game, but it removes what is basically a cheat - fast forward to freeze rotation - and makes it somewhat more realistic, at what seems like a trivial cost.

[Darndello]

As much as i know it would cause lag to rotate something in such high speed. But adding a line of code to remember it's rotation and restart it after the end of timewarp. I have to Agree.

[Burninate]

As much as i know it would cause lag to rotate something in such high speed. But adding a line of code to remember it's rotation and restart it after the end of timewarp. I have to Agree.

I don't see that this would cause any issue - the game can just poll the physics engine once per frame to check for rotation like it does now.

I think it would look *confusing* watching a ship tumble at 10k RPM subjective time in a deep warp, but the current system doesn't really make sense.

[Yourself]

I don't see that this would cause any issue - the game can just poll the physics engine once per frame to check for rotation like it does now.

I think it would look *confusing* watching a ship tumble at 10k RPM subjective time in a deep warp, but the current system doesn't really make sense.

Indeed, basically you're asking that rotation be put on rails. I don't see any problem with that. In order to rotate something you don't need to simulate all the orientations in between*, so there's not a huge computational cost to doing this.

*Technically there could be some trickiness dealing with torque-free precession.

[jebster]

I think that you shouldn't be able to timewarp while your ship is rotating quickly. Just as "can't timewarp while ship is under acceleration" you should get a message "can't timewarp while rotating." You'd have to fix your rotation so that you're hardly moving, and only then can you timewarp. I admit that the instant-halt rotation timewarp exploit has made flying much easier than it should be.

[NGTOne]

I think the real issue is that the rotation for each part is calculated separately - i.e. your spacecraft doesn't rotate as a rigid body (this is unnoticeable for small capsules, but incredibly prominent for larger objects with large cantilevered components - hence the long-lamented "wobbly rocket problem"). Timewarp puts the spacecraft on rails, and models it as an ideally rigid body (and snaps all parts back to their original positions as long as they haven't broken off). Any model for timewarp rotation would have to take into account either the nonrigid behaviour of the spacecraft (FYI: I just described physwarp, which does this simply by increasing the forces applied in some fashion based on warp factor, sometimes with unintended results because the strengths of the part joints aren't multiplied to compensate), or some way to translate the nonrigid rotation of the non-warped craft to rigid rotation.

Edited August 16, 2013 by NGTOne

[Ernest3.14]

Any model for timewarp rotation would have to take into account either the nonrigid behaviour of the spacecraft [...] or some way to translate the nonrigid rotation of the non-warped craft to rigid rotation.

How about calculating the center of mass and the net rotation, storing those and doing some math? Seems like a reasonable approximation, especially if your craft hasn't fallen apart due to wobbling already.

[Yourself]

I think the real issue is that the rotation for each part is calculated separately - i.e. your spacecraft doesn't rotate as a rigid body (this is unnoticeable for small capsules, but incredibly prominent for larger objects with large cantilevered components - hence the long-lamented "wobbly rocket problem"). Timewarp puts the spacecraft on rails, and models it as an ideally rigid body (and snaps all parts back to their original positions as long as they haven't broken off). Any model for timewarp rotation would have to take into account either the nonrigid behaviour of the spacecraft (FYI: I just described physwarp, which does this simply by increasing the forces applied in some fashion based on warp factor, sometimes with unintended results because the strengths of the part joints aren't multiplied to compensate), or some way to translate the nonrigid rotation of the non-warped craft to rigid rotation.

Or when going into warp compute the total angular momentum of the craft and let it rotate as a rigid body. Warp doesn't have to be an all or nothing thing where we absolutely must preserve all physical behavior (because it already doesn't do this and it can't). In any case having the craft continue rotating as if it were a rigid body doesn't really seem like it's that game-breaking. Especially considering right now that warp is a really cheap way to reliably cancel all rotation of your craft period.

I suppose if you were absolutely hell-bent on preserving the "wobble" modes through time-warp you could do a simplified vibrational analysis of the craft and record the first couple of vibrational modes in addition to the rotation. Done right it turns into solving an eigenvalue problem, but it can actually only be done once for a particular craft (well, once for each stage). Not that any part of that is particularly simple or easy, but it is at least technically possible.

[NGTOne]

How about calculating the center of mass and the net rotation, storing those and doing some math? Seems like a reasonable approximation, especially if your craft hasn't fallen apart due to wobbling already.

"Net rotation" is a somewhat vague term, and what's more, there are a number of different approximation models that COULD be used, each with different results. For instance,

1. The rotation of the part closest to/farthest from CoM, ignoring the rotation of all other parts.

2. The individual angular rotation of all parts, divided by distance from CoM and averaged. May yield strange results due to how KSP handles distances.

3. The "navball rotation" - i.e. the rotation of the currently selected command part, again ignoring the rotation of all other parts.

These are just a few that I can think of off the top of my head, there are undoubtedly others.

EDIT:

Ninja'd.

Or when going into warp compute the total angular momentum of the craft and let it rotate as a rigid body. Warp doesn't have to be an all or nothing thing where we absolutely must preserve all physical behavior (because it already doesn't do this and it can't). In any case having the craft continue rotating as if it were a rigid body doesn't really seem like it's that game-breaking. Especially considering right now that warp is a really cheap way to reliably cancel all rotation of your craft period.

I suppose if you were absolutely hell-bent on preserving the "wobble" modes through time-warp you could do a simplified vibrational analysis of the craft and record the first couple of vibrational modes in addition to the rotation. Done right it turns into solving an eigenvalue problem, but it can actually only be done once for a particular craft (well, once for each stage). Not that any part of that is particularly simple or easy, but it is at least technically possible.

The real question is, how computationally expensive is it, especially given Unity's limited ability to cope with the physics problems that KSP as it stands currently presents?

Edited August 16, 2013 by NGTOne

[Eric S]

Actually, one of the devs mentioned this back the weekend before 0.21 came out, that they intended to do a compromise system that depending on the rotational velocity, would either save the rotation, or kill it, during warp.

[Dunbaratu]

Yeah constant rotational velocity on rails is trivial to calculate. Plug time=t into three formulas that are simply:

(A*t) mod 2pi

(B*t) mod 2pi

(C*t) mod 2pi

where A,B,and C are your constant rotational velocities you stored for the 3 axes of rotation given in radians. (If you do it in degrees instead, then change "mod 2pi" into "mod 360".)

As for the comment about it being a cheat to use time warp to kill rotation - I'd agree only if the rotation wasn't buggy in the first place with mysterious sources of rotational acceleration coming from nowhere when you accidentally had a part clipping somewhere, so I often use time warp as a workaround for this game simulation error.

[Nuke]

just a nitpick, you would probibly do this as a quaternion operation, but thats pretty much it. no sane game programmer uses eulers internally.

[technicalfool]

just a nitpick, you would probibly do this as a quaternion operation, but thats pretty much it. no sane game programmer uses eulers internally.

Well, they do if they don't need massive accuracy (Euler is a lot simpler than RK4) or if they're Kerbal developers who feel like invoking the Kraken for a laugh.

[Zeroignite]

iirc, KSP does use quaternions for physics calculations.

[Yourself]

The real question is, how computationally expensive is it, especially given Unity's limited ability to cope with the physics problems that KSP as it stands currently presents?

Not as much as you might think, especially since it can be effectively pre-computed for a given set of parts. Essentially you end up computing the eigenvectors of a given linear system. And you wouldn't even really be interested in all the eigenvectors, just the ones with the largest eigenvalues (because they'd have the most pronounced effect on the dynamics). There's many algorithms to do this, but they're not necessarily easy to implement (and that's ignoring the hard part of actually coming up with the linear system in the first place, which requires a bit of ugly mathematical analysis). Since we'd only be interested in a few of the eigenvectors, iterative approaches would likely be the easiest to implement and the fastest to execute.

That said I still think this would be a stupid idea. Not for performance reasons (I've done quite a bit of linear algebra in C# .NET and you can get away with some surprisingly hairy calculations in real time), but mostly because the mathematics behind it is unnecessarily complicated and adds very little gameplay value.

[King Arthur]

Until there is an alternative reliable way to immediately cancel an inpending RUD, kill spin forces resulting from phantom forces/rounding errors, or soundly killing rotation manually (SAS and MJ's Kill Rot are both crude at killing rotation) I can't say I'd like this to be implemented.

Also, regarding time warping to kill rotation being a "cheat": The only person you're cheating is yourself.

[Psycix]

Also, regarding time warping to kill rotation being a "cheat": The only person you're cheating is yourself.

It's simply too accessible not to use.

Also, thanks for making me feel bad about myself...

[Yourself]

It's simply too accessible not to use.

Also, thanks for making me feel bad about myself...

Don't feel bad, it's still a single player sandbox, so there isn't really any cheating at all. Play how you want.

I mean, really, it's a single player sandbox, of course you're only "cheating yourself" there's no one else to cheat!

[Dunbaratu]

It's simply too accessible not to use.

Also, thanks for making me feel bad about myself...

I don't use it unless the rotation itself is caused by a bug in the first place, so in that case it's not cheating it's a bug workaround. (There's a bug that causes crafts to have rotational accelerations applied to them if the VAB clipped any parts into each other without you noticing. And once you have clipped parts it's nearly impossible to find them since one part ends up hiding the other from view.)

[Burninate]

It's mathematically simple, but...

A thought on the more complex problem of an interface that makes it obvious what's going on, without presenting a grey blur:

On warp, a 95% transparent grey ball appears around the CoM. It has radius equivalent to the size of the craft, with three dashed hemispherical circumference lines, a 'current heading' indicator in white on the surface of the sphere, and the traditional red-green-blue unit vectors indicating dimensions relative to current heading, emerging from the CoM. This ball does not obscure the craft, and can rotate freely at whatever the appropriate angular velocity is, without affecting the camera. On exit warp, the craft aligns to the ball's heading and orientation, and angular velocity.