# 2 component unit vector

Is it possible to store a 3d unit length vector with only 2 components, for example as coordinates on a unit sphere? It seems possible but I have never seen anyone do this. Would this be at all practical?

• A unit sphere, by its definition as a 3 dimensional object, would require a 3 value point to reference any surface coordinate. You could calculate those values by storing a rotation angle for the horizontal and vertical planes, but that seems likely to be too computationally expensive to be worth a memory footprint savings of 1 value per vector. en.wikipedia.org/wiki/Space%E2%80%93time_tradeoff Sep 12, 2014 at 21:33
• I suppose you're right, it doesn't make sense that sending 4 less bytes to the shader would balance the extra trig calculations needed. Sep 12, 2014 at 21:53
• Especially considering that you can store thousands of vectors in the same space as a single low res texture. Under normal circumstances, vector objects are not going to be a significant component of your total footprint. Sep 12, 2014 at 21:59
• @LLL79 while the sphere exists in 3D space, the surface itself is 2D thus it's possible to address it with 2D coordinates Sep 13, 2014 at 13:17
• If you want to put it through a projection matrix, sure, but that's not a free operation either. Sep 15, 2014 at 14:09

No, it is not usually possible. But when it is, it’s quite useful.

The problem is that there will always be two possibilities for the missing coordinate. For instance, if you store [x,y] as [0,0] this could mean the unit vector was either [0,0,1] or [0,0,-1] and without additional information there is no way to tell which of the two it was.

Fortunately, in some cases that information is known. For instance if the vector is a normal to a surface, most of the time it is pointing outside the surface and so a local coordinate system can be chosen so that the missing coordinate is always positive.

Memory is indeed cheap nowadays; however, it is not always the case (think mobile platforms) and what’s not so cheap is the GPU bandwidth. The main advantage of packing vectors is that they help reduce that bandwidth usage.

So, what you mention does exist and does have practical uses, the most prominent example being the compression of normal maps (the Unity engine uses this technique to compress normal maps, and so does the C4 engine) and normal buffers (see this comprehensive article on compact normal storage that explores several other packing techniques, and this other article for yet another method).

Yes it's possible. Instead of using 3 cartesian coordinates [x, y, z] you can use 2 spherical coordinates [theta , phi] to represent any 3d unit vector. It depends on the case if it's useful or not. For example it can be useful for compressing animation data. There are also other representations you could use and there was actually an interesting paper released about compact 3d unit vector representations recently.

For many cases, it's possible. But it's not practical.

Pros:

• Reduced memory requirements

Cons:

• Reduced precision
• Increased complexity

By today's standards, memory is pretty cheap compared to time. Implementing and using a two component vector will take more development time as well as processing time whenever it's used. Keeping a three component vector only takes a little more memory, and is pretty straight forward to implement and quick to process.

There are, of course, exceptions to this. As explained in Sam's answer, where you can easily embrace the reduced precision I mention. You embrace reduced precision when you can make assumptions about what your third coordinate is going to be (typically, -1, 0, or 1 depending on the context).

• "But it's not practical" is simply not true. It's actively used in shipped products. See the last paragraph in Sam Hocevar's reply. Sep 13, 2014 at 9:49
• @bogglez It's not true all the time, but it's true a majority of the time. I took the question to be asking about general ways of compressing a three component vector into a two component vector. Sam's answer is essentially a case where one would accept the reduced precision because it's not required. I've edited my answer to allow for those exceptions.
– House
Sep 13, 2014 at 13:46
• While memory may be cheap, memory bandwidth is not, and processing power actually grows faster than memory bandwidth. It's quite common tradeoff for example to use 2-component DXN format for improved normal map quality with some additional calculations in a shader to reconstruct the normal. Sep 13, 2014 at 14:06