Camera Gimbal Lock?

[apLundell]

Has mouse camera control changed recently? 

Because recently I've been noticing gimbal locks a lot when trying to mouse the camera around a space-craft in flight.  It can be pretty frustrating if it happens at a critical moment.  (Especially as I feel like controlling a 3d camera centered around a point is a solved problem in computer graphics.)

Is this new, or was it always like this and I just didn't notice?

[maceemiller]

A new change in 1.0.5 is if you double click the right mouse button you will switch to a moving camera around your craft without having to hold any buttons. It can be odd at first but I actually find it useful now.  Right click again to switch back.

Edited December 4, 2015 by maceemiller

[TrooperCooper]

3 hours ago, maceemiller said:

A new change in 1.0.5 is if you double click the right mouse button you will switch to a moving camera around your craft without having to hold any buttons. It can be odd at first but I actually find it useful now.  Right click again to switch back.

 

Or deactivate it in the settings menu. Its annoying, especially when you fiddle with a maneuver node with the precise node mod.

[HvP]

Am I correct that you are referring to the fact that the camera view hits a hard limit at the zero-degree mark, or axis, on the sphere of rotation? You spin the camera a full 360 degrees horizontally but not continue past 0 "above" or "below" the sphere of rotation.

Yes, I find this behavior very frustrating, too. Double right-click does not solve this restriction. The only workaround is to toggle through different camera reference frames with the "V" key until you find an orientation that is adequate. Very difficult during EVA in space though.

[apLundell]

46 minutes ago, HvP said:

Am I correct that you are referring to the fact that the camera view hits a hard limit at the zero-degree mark, or axis, on the sphere of rotation? You spin the camera a full 360 degrees horizontally but not continue past 0 "above" or "below" the sphere of rotation.

Yes!  I assume it's a gimble-lock problem, but I suppose it could be some other similar limitation.

I guess I just never let it bother me before, for some reason it was really frustrating me yesterday.

 

It seems so weird though.  Is it intentional?   This kind of camera problem is a common newbie mistake, but there's no way in heck the KSP team could be even remotely considered newbies to 3d math!

 

13 hours ago, maceemiller said:

A new change in 1.0.5 is if you double click the right mouse button you will switch to a moving camera around your craft without having to hold any buttons. It can be odd at first but I actually find it useful now.  Right click again to switch back.

Huh, I'll give this a try.  Thanks.

 

[katateochi]

I guess that camera pan limit at 0 degrees when panning down has always been there so I've just accepted it and don't really think about it.  

The thing that really melts my boosters is the way the camera pans in the SPH.  You won't notice it if you have a small craft positioned close to the ground, but on larger craft or if you've lifted the craft higher up in the SPH, when panning down to look at the top of the craft there is a point where the camera's pivot point is suddenly shifted forwards/down, resulting in the camera being plunged into the craft rather than ending up looking down on it.  This was a change that was added a few versions ago (just before 1.0 IIRC) and is so unpleasant that I can't believe it was intentional! I could understand it if the camera was high enough to be interacting with the ceiling but it happens much lower down than that.

 

[maceemiller]

At least you have it sorted now

Edited December 5, 2015 by maceemiller

[RuBisCO]

How to experience Gimal Lock in KSP

1. Go to the pole of any planet in KSP, -90° or 90°

2. Have a craft cross that pole exactly

3. Watch the camera instantly and even violently rotate 180°, you will also notice your 8 ball flip ordination instantly as well.

Even as you approach the pole you may notice the camera moving very oddly, in older verse of KSP I was able to get the krakan to rip crafts apart due to the violence of the camera flipping.

[jwbrase]

On Friday December 04, 2015 at 3:10 PM, apLundell said:

It seems so weird though.  Is it intentional?   This kind of camera problem is a common newbie mistake, but there's no way in heck the KSP team could be even remotely considered newbies to 3d math!
 

I would assume that it is intentional, as otherwise the effects of parallel transport would add up as you panned the camera around and users might end up panning themselves into a situation where the camera was upside down during atmospheric flight. In my experience, programs that are focused on viewing 3D objects tend to allow the user to rotate the camera around the object arbitrarily without gimbal lock, but flight sims pretty much universally use an arrangement similar to KSP's, because preventing parallel transport of the horizon is a bigger concern. KSP switches between an axis perpendicular to the surface in atmospheric flight, and one parallel to the rotational axis of the planet in orbital flight, and the latter is where gimbal locking becomes most noticable. It might be good if they allowed the user to switch freely between the two modes and added a mode with the gimbal axis of the camera parallel to the yaw axis of the ship (perpendicular to the wing/fuselage plane for spaceplanes).

[Aloriel]

The clearest sign to me that the gimbal lock is intentional is because I am also a Unity programmer. In the projects I have worked on, I have found that Unity, by default, has no gimbal lock of any kind. This means that Squad has intentionally added it.

In fact, I've found that it is quite difficult to *add* gimbal lock in Unity. The default system uses quaternions, which have no gimbal lock, and thus all of the rotation commands for cameras and objects also have no gimbal lock. So, I can only imagine what they went through to actually achieve it. I am assuming something on the order of rewriting many thousands of lines of code, simply to introduce gimbal lock where none exists.

[Renegrade]

I'm pretty sure the default modes have always had this 'issue'.  It hasn't noticeably changed in recent versions.

@TrooperCooper - thanks for pointing out the setting for the double click issue.  That was annoying me quite a bit! 

 

2 hours ago, Aloriel said:

In fact, I've found that it is quite difficult to *add* gimbal lock in Unity. The default system uses quaternions, which have no gimbal lock, and thus all of the rotation commands for cameras and objects also have no gimbal lock. So, I can only imagine what they went through to actually achieve it. I am assuming something on the order of rewriting many thousands of lines of code, simply to introduce gimbal lock where none exists.

Thousands?  I'd say it's about thirty lines of code in ANSI C to write a simple fixed Euler system that creates a matrix that you could pass to OpenGL for the view matrix.  I stopped working with LPHURTSMYHEAD err I mean DirectX back in the DX5 era (actually more like DX3, although I did upgrade some of my code to use the call that lets you set resolution AND refresh rate from DX5 (DX3 didn't let you set refresh rate when selecting a mode)), but I imagine it's probably only forty or fifty lines for DirectX too.

Random aside:

Firefox says that 'quaternions', 'gimbal', 'LPHURTSMYHEAD' and 'DirectX' aren't actually words.  Firefox is wrong.  Also it failed to automatically ™ the DirectX™ word.  So, if I don't ever post again, I got sued out of existence. And here I thought they were finally making progress, what with an official 64-bit Windows binary and all...

[RuBisCO]

Well what ever the case the camera's clearly operate on Euler angles, and if it is not Unity's fault, then why? 

[Aloriel]

On 1/13/2016 at 9:37 AM, Renegrade said:

I'm pretty sure the default modes have always had this 'issue'.  It hasn't noticeably changed in recent versions.

@TrooperCooper - thanks for pointing out the setting for the double click issue.  That was annoying me quite a bit! 

 

Thousands?  I'd say it's about thirty lines of code in ANSI C to write a simple fixed Euler system that creates a matrix that you could pass to OpenGL for the view matrix.

Simple, yes. However, nothing in Unity is done to a simple level. They are extremely thorough in making sure you have lots of options. If you want to over ride the controls, you have to over ride quite a lot of stuff, or write up a completely new set of instructions. Plus, Unity runs in both DirectX and OpenGL, so you need both written. You would also need to translate those Euler coordinates into Unity's coordinate system for final display, which is in quaternions.

 

And yes, Firefox is wrong. Those are words... well, except the LPHURTSMYHEAD one, even if true. LOL