顶点颜色内部乘以alpha(Android,OpenGLES1)

时间:2013-11-22 12:33:31

标签: android opengl-es blending

以下仅在某些设备上发生,到目前为止三星S3 Mini和LG-P690。

我简单地淡化了一些单纹理三角形。我这样做是通过修改相应颜色数组的alpha值来实现的。所以最终的顶点颜色是1,1,1,其中a从0到1。 混合模式为s = SrcAlpha d = OneMinusSrcAlpha,启用混合,仅使用一个纹理单元,启用颜色阵列,禁用颜色逻辑运算,禁用tex-env,禁用照明。实际上,所有渲染状态都很好。

对前面提到的设备的影响看起来像顶点颜色与其alpha分量预乘。看起来好像我提供了1 * a,1 * a,1 * a,a的颜色 因此,除了理想的渐弱之外,我还得到一个灰色的阴影,直到三角形完全消失。

附加说明:

  • 手动加载纹理,它们肯定是正确的格式,没有预先乘以的alpha或其他,RGBA,没有压缩。

  • 颜色正确,没有任何错误导致我偶然提供灰色。

  • 相同的代码可以在许多设备上运行,包括iOS,Windows和许多Androids。

  • 当我提供1,0,0的颜色时,我会得到一个具有相同预乘效果的红色三角形。

  • 提供1 / a,1 / a,1 / a,a的颜色以补偿效果不起作用,因为这些值被钳制为1.

  • 通过提供1 * a,1 * a,1 * a的颜色,我可以在所有设备上创建完全相同的效果。

对我来说,这些看起来像是这些设备的OpenGLES1实现中的严重错误。 但是吗?有人注意到那些(或其他)设备的行为?

编辑:

以防万一有人遇到同样的问题:解决方法是在这些设备上实际投放预乘的资产/颜色(这也适用于不受此影响的设备)。

  • 在预先加载图片数据的RGB之后用A标记并标记那些修改过的纹理。
  • 在渲染过程中,如果要将这样的纹理用于混合,则使用s = One d = OneMinusSrcAlpha而不是s = SrcAlpha。
  • 预乘顶点颜色。
  • 平局。

0 个答案:

没有答案