EVE General Discussion

I know this has been an issue for players for years and not just myself as Ive had the conversation a few times with others over the years. How you cant really fix the camera to point directly up or down and therefore theres a small cone that you cant really point yourself well too. For me it mostly applied to undocking in amarr stations to make the best instaundocks but has been an issue in other times too.

Is this something CCP can fix? Is it an unintended result of something? What was the reason for it in the first place?


CCP response would be cool too but Ill take others opinions, answers, etc too. Kinda just curious about it as a "feature" in the game from a design standpoint.

OP, I know this isn't about your total issue with aligning up/down, however on this specific issue of creating instundocks on Amarr stations, if you turn on the tactical overlay, the undock will produce the altitude line from the station, so you only need to line the dot up in the centre of the tactical overlay and you'll be perfectly aligned down from the undock:

http://puu.sh/mSR32/db77e69de6.jpg

even once you pull range off the station, you'll still have the light you can line up:

http://puu.sh/mSRmf/3bc8cbbab5.jpg

fyi, press the down arrow key and you go straight down

Shoulda used quaternions.

Don't think it's something they can fix without changing the graphics engine; it's a limitation that's built into the way they simulate 3-D. "Up" and "down" are universal, everything is aligned upright, and you can't "pass through" the vertical axis.

Gimbal lock to one side, your mind actually works much better when navigating if it has a point of reference: In this case, "up" and "down".

It's really common to see in SCUBA divers: When deep sea diving you can actually "forget" which way is up when you don't have an immediate and obvious reference point. It's really disorienting.

Yes, it's not going to be that serious in a game like Eve on a 2D screen, but reference points allow us to calculate routes, directions and movements MUCH faster.

This is what I do.

The short cut is CTRL + D.

You've asked an insightful question! In principle it might be possible to fix it, but it would require a major reworking at the most basic mathematical level of the way Eve internally represents 3D space, would require touching nearly everything, and would yield minimal practical benefit.

The issue is a concept known as gimbal lock. When you represent an orientation in 3D space in spherical coordinates, you use three values:

Azimuth is an angle measured on a circle centered on your up/down pole. On the Earth, think of longitude.

Altitude is an angle measured on a circle perpendicular to the equator of your space. On the Earth, this angle is latitude.

Radius is the distance of an object from the center of the circle. For a sphere, all points fall at the same radius, but of course to represent all points in space, you need radius to be arbitrary.

Gimbal lock is the term for the fact that at an altitude angle of 90 or 180 degrees, in other words at either up-down pole, all azimuth values represent the same location. Furthermore, if you try to head "south" from, say, the north pole, that's ambiguous as to what direction you need to go.

Gimbal lock can cause conversions of directions from spherical to rectangular coordinates to be poorly-defined, in the sense that more than one representation can exist for the same direction. Also, using rectangular coordinates in general is not a great solution, because you often will want to consider the effect of rotating around an axis in a way that's only easy in spherical coordinates.

There are a couple of solutions. One is to use an alternate coordinate space. "Quaternions" are a common way of representing a 3D rotation in a 4D space so as to prevent any poorly-defined conversions. However, using quaternions requires that you do not attempt to apply rotations specified in spherical coordinates to the object you're modeling, otherwise you are back where you started with the gimbal lock problem.

Another solution, Eve's solution, is just to avoid orienting objects toward the poles. If you prevent rotating up more than, say, 89.5 degrees, you won't have gimbal lock problems, because you won't have valid orientations that convert to multiple representations in your coordinate scheme.

Be sure to check out Wikipedia's page on gimbal lock, particularly for the story about how gimbal lock in the physical gyroscopes of the lunar lander's inertial guidance system adversely affected Apollo 11's moon landing. NASA's solution, rather than to avoid problematic orientations, was instead to sound an audible alarm and make the system stop functioning until it was manually reset.

I think I prefer our way better, though of course we have the luxury of establishing an "up" and "down" in space, which NASA did not.

there is another way of dealing with that. You persist the rotation matrix between frames and only apply relative rotations to it (delta between current state and new state). Don't forget to normalize the rotation matrix once per tick or it will break real fast. Gimbal lock would only occur if you would rotate 90 degrees per frame, and you don#t want to do that anyway. Now you can have gimbal lock free rotation while using only "highschool" math and without complex numbers.

(i might have forgotten something since the last time i wrote things like that was like 15 years ago, OpenGL FTW)