# How to linearly transform vertices for large coordinate systems

Alright, so I'm working on a space game and well, I want it to have a lot of space! So I need a large coordinate system and for my rendering pipeline to not suffer from "vertex jittering" due to floating point rounding errors introduced in the world to view space matrix transformation.

So far I'm having some luck with a technique discusses in GPU Pro that was used for Just Cause 2. However, it's not quite there. It looks like the "world" (including the player's ship) is orbiting around my camera instead of the camera adjusting it's orientation and position to stay behind the player's ship when it rotates. It doesn't do this with the traditional World x View x Projection transformation.

Anywho, the technique basically merges the world and view space's translation matrices by translating directly to the object's offset from the camera.

The transformation is

objectScale x objectRotation x objectOffsetFromViewPosition x viewRotation x Projection

Where the offset is a translation matrix built from the object's world position - view position.

I've always built my view matrix simply using the XNA library's XMMatrixLookAtLH() function so I'm thinking I might be missing another vital aspect of the view matrix transformation. My view rotation matrix at the moment is only built from a quaternion representing the camera's orientation.

What am I missing or what is the correct way to build this transformation?

• AFAIK the almost a same system is used to create games for handheld devices (specially psp). I've once heard from a friend of mine that rotating camera has a great impact on rendering performance. I guess you can use the same materials provided for those games. Jan 26, 2012 at 5:02
• Is that supposed to be a right or left sided multiplication? Jan 26, 2012 at 6:57
• Not sure, but the vertex's position vector is on the left side. Vector x Transformation Matrix Jan 26, 2012 at 13:28
• Have you considered Q? Jan 26, 2012 at 14:11
• First time I've seen it but I think it may require more work than my current solution. Also it sounds I'd have to cast the Q datatype to a float before sending it through the rendering pipeline and don't think that would help me since the rounding errors would still occur. Jan 26, 2012 at 16:44

Alright, it looks like I solved my problem. The modified transformation presented in the question was correct. However, I was able to remedy the odd rotational movement by inverting the view's rotational matrix. (I realized the camera was rotating in the opposite direction than I wanted)

Final transformation order

Scale x Rotation x camOffset x InvertMatrix(viewRotation) x projection

As for jittering due to floating point errors in dealing with my coordinate system and placing objects (such as the camera), I ended up using 64 bit ints instead of 32 bit floats. Now I can be accurate down to a millimeter across a coordinate system as large our solar system. (and with more precision if needed!)

This idea was provided with the help of some GDSE users in the chat room and this page.

As for the depth buffer, this too experiences floating point issues in the form of z-fighting with large distant astral bodies. To remedy this, I render through two different passes based on their distance from the camera. Astral bodies that won't present issues for my depth buffer are ran through my standard pipeline while distant bodies are rendered using a painter's algorithm without writing to the depth buffer.

• You might try using double precision for positions to remove jitter, or at least lessen it. It could affect performance however, especially on the XBox if you're using that. Jan 28, 2012 at 4:36