OpenGL 是否会限制每个纹理阶段的输出?

发布于 01-04 06:53 字数 649 浏览 2 评论 0原文

使用 OpenGL 1.4 固定功能多重纹理时,每个纹理阶段的输出在传递到下一个阶段之前是否都被限制为 [0, 1]?

规范说(第153页):

如果TEXTURE_ENV_MODE的值为COMBINE,则纹理函数的形式取决于COMBINE_RGB和COMBINE_ALPHA的值,根据 表 3.24。然后,纹理函数的 RGB 和 ALPHA 结果分别乘以 RGB_SCALE 和 ALPHA_SCALE 的值。结果是 固定在 [0, 1]。

但在我的测试中,这并没有发生。我的 RGB 分量纹理环境是:

  • 第 1 阶段:从 GL_TEXTURE 中减去 GL_CONSTANT,其中整个纹理为黑色,GL_CONSTANT 颜色为 (.5, .5, .5, 1.0)
  • 第 2 阶段:将 GL_TEXTURE 添加到 GL_PREVIOUS,其中纹理是测试彩虹。

我将阶段 1 的 GL_CONSTANT 颜色设置得越亮,输出就​​越暗。

是否有某种状态我可以启用以获得我期望的夹紧?

When using OpenGL 1.4 fixed-function multitexturing, is the output of every texture stage clamped to [0, 1] before being passed onto the next stages?

The spec says (page 153):

If the value of TEXTURE_ENV_MODE is COMBINE, the form of the texture function depends on the values of COMBINE_RGB and COMBINE_ALPHA, according to
table 3.24. The RGB and ALPHA results of the texture function are then multiplied by the values of RGB_SCALE and ALPHA_SCALE, respectively. The results are
clamped to [0, 1].

But in my test, that didn't happen. My texture environment for the RGB components is:

  • Stage 1: subtract GL_CONSTANT from GL_TEXTURE, where the entire texture is black, and the GL_CONSTANT color is (.5, .5, .5, 1.0)
  • Stage 2: Add GL_TEXTURE to GL_PREVIOUS, where the texture is a test rainbow.

The output gets visibly darker the brighter I make Stage 1's GL_CONSTANT color.

Is there some sort of state I can enable to get the clamping I expect?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

懒的傷心2025-01-11 06:53:35

这是一个驱动程序错误的可能性很大。由于固定功能硬件不再存在,因此所有这些都在着色器中进行模拟。由于夹紧不是着色器中的默认行为,因此他们必须记住在组合阶段之间进行夹紧。如果他们忘记测试它......哎呀。

不管怎样,你无能为力。如果你的实现没有像规范所说的那样严格,你能做的最好的事情就是提交一份错误报告。

Odds are good that it's a driver bug. Since fixed-function hardware doesn't exist anymore, it's all emulated in shaders. And since clamping is not default behavior in shaders, they would have to remember to clamp between combine stages. And if they forgot to test it... oops.

There's not much you can do, either way. If your implementation doesn't clamp like the spec says it should, the best you can do is file a bug report on it.

凉城凉梦凉人心2025-01-11 06:53:35

是的。在规范第 3.8.13 章中,它说:

Cf和Af是传入片段的主要颜色分量;
Cs 和 As 是纹理源颜色的分量,源自
过滤后的纹理值 Rt、Gt、Bt、At、Lt 和 It 如下所示
桌子
3.21; Cc和Ac是纹理环境颜色的分量; Cp 和 Ap 是先前纹理产生的分量
环境(对于纹理环境 0,Cp 和 Ap 与 Cf 相同
和 Af ,分别); Cv 和 Av 是原色分量
由纹理函数计算。

所有这些颜色值都在 [0;1] 范围内。纹理函数在表中指定
3.22,
3.23,和
3.24.

我不知道你的具体情况,但这回答了你的第一个问题(和标题)。

Yes. In the spec, chapter 3.8.13, it says:

Cf and Af are the primary color components of the incoming fragment;
Cs and As are the components of the texture source color, derived from
the filtered texture values Rt, Gt, Bt, At, Lt, and It as shown in
table
3.21; Cc and Ac are the components of the texture environment color; Cp and Ap are the components resulting from the previous texture
environment (for texture environment 0, Cp and Ap are identical to Cf
and Af , respectively); and Cv and Av are the primary color components
computed by the texture function.

All of these color values are in the range [0;1] . The texture functions are specified in tables
3.22,
3.23, and
3.24 .

I would not know about your particular case but that answers your first (and title) question.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文