opengl glMaterialfv 与 glMaterialiv
将材质数据传递给 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 倍只是为了将它们转换为浮点数。
While passing material data to opengl (to be used in a shader):
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);
First one works beautifuly, but the second one only gives a black mesh. Both were used in the exact same context (basically I wrote the first one and then the second one replaced the first).
Does anyone have any idea why that is? glMaterialiv would really make my life easier (if I can get it to work) because I keep my colors as rgba bytes and I'm not sure if I want to make them 4 times bigger just to convert them to float.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
glColor3i 和 glMaterialiv 都采用 [0, INT_MAX] 范围内的颜色，INT_MAX 为 2^31 - 1。这解释了您的网格是黑色的，255 相当于为浮点数传递 0.000000119。
从技术上讲，将其作为浮点数或整数传递应该没有多大关系。在您的示例中，您已经将各个组件存储为其原始大小的 4 倍，因此没有损失。
我什至不相信跳过 int ->浮点转换将产生任何性能增益，因为驱动程序仍可能将事物转换为 CPU 端的浮点。我推测，测试必须证明这一点。
Both glColor3i and glMaterialiv take colors in the range [0, INT_MAX], with INT_MAX being 2^31 - 1. This explains your mesh being black, 255 is the equivalent of passing 0.000000119 for floats.
Technically, passing it either as floats or ints shouldn't matter much. In your example, you are already storing the individual components at 4 times their original size, so no loss there.
I´m not even convinced passing skipping the int -> float conversion will yield any performance gain, as the driver might still convert things to float on the CPU side of things. I'm speculating there, testing would have to prove that.