Арифметика с фиксированной точкой с вершинными шейдерами
Если я использую фиксированную точку (или целые числа с 1, описывающим наименьший игровой блок) для описания моих вершинных векторов, как я могу настроить преобразования OpenGL / eigen для работы с ним? Если я делаю это в моем вершинном шейдере:
gl_Position = projectionMatrix * viewMatrix * modelMatrix * vec4(in_Position, 1.0)
Если я передам in_Position как vec3 из GL_INT, а я передам матрицы как GL_FLOAT mat4, будет ли выполнено правильное приведение? Есть ли стоимость исполнения?
Можно ли подготовить мои матрицы преобразования так, чтобы они также были в фиксированной точке?
Это делается с помощью 2D-игры, что, я думаю, делает ее более выполнимой, чем с 3D. Я действительно предпочел бы точность, так как кажется, что на больших картах наблюдается ухудшение положения, когда вещи уходят далеко от начала координат. Я понимаю, что, возможно, смогу избежать неприятностей, если только положение объекта является целым числом, а вершины все еще описываются как плавающие. Тем не менее, я думаю, что моя схема столкновения будет работать лучше с вершинами с фиксированной точкой. Какая разница в производительности?
Решение
Это будет означать конвертацию int в float, которая оштрафует ваши выступления. Вы должны привести in_Position к vec3 при копировании из CPU в GPU. Если вы используете объект Matrix для хранения их на CPU, вы можете привести их к:
MatrixXf data_as_float = data_as_int.cast<float>();
Затем вызовите glBufferData с data_as_float.
Другие решения
Хорошо, после некоторых экспериментов, я остановился на решении.
gl_Position = projviewMatrix * vec4(ivec3(in_Position - camera), 1.0);
camera это uniform uvec3, а также in_Position это uvec3 ввод позиции. Перевод выполняется как отдельная операция, а масштабирование, поворот и проекция вида выполняются с помощью mat4 плавает (projviewMatrix) по-прежнему.
Необходимо позаботиться о том, чтобы обеспечить правильные типы и команды ввода (glVertexAttribIPointer) используются. OpenGL кажется очень стремятся привести к плавающему типу, но оставить данные целочисленного типа, поэтому любая небольшая ошибка приведет к искаженному вводу.
Это просто невозможно осуществить projviewMatrix умножение в фиксированной точке, поскольку у вас нет доступа к промежуточному 64-битному хранилищу для умножений. Только если биты используются in_Position а также projviewMatrix сумма до 32 приблизит удобство использования, но, учитывая, что координаты для рендеринга будут настолько близки к началу координат, и никаких дополнительных операций не будет получено (все еще нужно сдвигаться после умножения, GPU будет занимать столько же времени для чисел с плавающей запятой, сколько в целых числах), нет никаких причин выполнять арифметику с фиксированной точкой после того, как положение было отцентрировано камерой.
Конечно, это игнорирование королевской боли, которая заключается в том, чтобы фактически манипулировать данными о целочисленных позициях. Я действительно не рекомендовал бы это.