具有顶点着色器的定点算术

Question

If I use fixed-point (or integers with 1 describing the smallest game unit) to describe my vertex vectors, how can I setup OpenGL/eigen transformations to work with it? If I'm doing this in my vertex shader:

gl_Position = projectionMatrix * viewMatrix * modelMatrix * vec4(in_Position, 1.0)

If I pass in_Position in as a vec3 of GL_INT, while I pass in the matrices as GL_FLOAT mat4, will the proper casting be done? Is there a performance cost?

Is it possible to prepare my transformation matrices to be in fixed-point as well?

This is being done with a 2D game, which I think makes it more feasible than with 3D. I would really prefer the accuracy, since it seems there is degradation of position on large maps when things get far away from the origin. I realize I could probably get away with only object position being an integer while the vertices are still described as floats. However, I think my collision scheme will work better with fixed-point vertices. What is generally the performance difference?

Answer 1

This will imply a int to float conversion that will penalize your performances. You should cast in_Position to vec3 at CPU to GPU copy time. If you use a Matrix object to store them on CPU, you can cast them with:

MatrixXf data_as_float = data_as_int.cast<float>();

Then call glBufferData with data_as_float.

Answer 2

Ok, after some experimentation, I've settled on a solution.

gl_Position = projviewMatrix * vec4(ivec3(in_Position - camera), 1.0);

camera is a uniform uvec3 , and in_Position is the uvec3 position input. Translation is performed as a separate operation, while the view scaling, rotation, and projection is done with a mat4 of floats ( projviewMatrix ) as usual.

Care must be taken to ensure the proper types and input commands ( glVertexAttribIPointer ) are used. OpenGL seems very eager to cast to float yet leave the data in an integer type, so any small error will result in mangled input.

It simply is not feasible to perform the projviewMatrix multiply in fixed-point, since you do not have access to an intermediary 64-bit storage for the multiplications. Only if the bits used by in_Position and projviewMatrix sum to 32 would it approach usability, but considering that coords for rendering will be so close to the origin and no extra ops are gained (still need to shift after multiply, GPU will take as long for floats as ints), there is no reason to perform fixed-point arithmetic after the position has been centered by camera.

Of course, this is ignoring the royal pain it is to actually manipulate the integer position data. I really wouldn't recommend it.