opengl glMaterialfv против glMaterialiv - PullRequest
Новая
       25

opengl glMaterialfv против glMaterialiv

1 голос
/ 15 мая 2011

При передаче данных материала в opengl (для использования в шейдере): 


float white[4] ={1.0f,1.0f,1.0f,1.0f};

glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT, white);
glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, white);
glMaterialfv(GL_FRONT_AND_BACK, GL_SPECULAR, white);


int whitei[4] = {255,255,255,255};
glMaterialiv(GL_FRONT_AND_BACK, GL_AMBIENT, whitei);
glMaterialiv(GL_FRONT_AND_BACK, GL_DIFFUSE, whitei);
glMaterialiv(GL_FRONT_AND_BACK, GL_SPECULAR, whitei);

Первый работает красиво, а второй дает только черную сетку.Оба были использованы в одном и том же контексте (в основном я написал первый, а затем второй заменил первый).

Кто-нибудь знает, почему это так?glMaterialiv действительно облегчит мою жизнь (если я смогу заставить ее работать), потому что я сохраняю свои цвета в байтах rgba, и я не уверен, хочу ли я сделать их в 4 раза больше, просто чтобы преобразовать их в плавающие.

1 Ответ

6 голосов
/ 15 мая 2011

И glColor3i, и glMaterialiv принимают цвета в диапазоне [0, INT_MAX], где INT_MAX = 2 ^ 31 - 1. Это объясняет, что ваша сетка черная, 255 эквивалентна пропуску 0.000000119 для чисел с плавающей точкой.Технически, передача его как float или ints не должна иметь большого значения.В вашем примере вы уже храните отдельные компоненты в 4 раза по сравнению с их исходным размером , так что без потерь.

Я даже не уверен, что пропуск пропуска преобразования int -> float приведет к какому-либо приросту производительности, так как драйвер все еще может преобразовывать объекты в плавающие на стороне процессора.Я размышляю там, тестирование должно было бы доказать это.

...