WebGL浮动模量行为 [英] WebGL Float modulus behaviour

查看:121
本文介绍了WebGL浮动模量行为的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在以下片段着色器上遇到奇怪的行为:

I am experiencing strange behaviours for below fragment Shader:

varying vec3 worldSpaceCoords;

uniform float rows;

void main() {

    float testNumber = 7.0;
    vec4 outputColor =  vec4(0.0,0.0,0.0,1.0);

    if(rows == testNumber) {
        if(worldSpaceCoords.x < 0.5) {

            outputColor.x = mod(floor(testNumber * worldSpaceCoords.y), rows ) / rows;

        } else {

            outputColor.x = mod(floor(testNumber * worldSpaceCoords.y), testNumber ) / testNumber;

        }

   } else {

        outputColor  = vec4(1.0,1.0,1.0,1.0);

   }

   gl_FragColor  = outputColor;

}

"testNumber"变量只是我的控制变量,用于检查传入的统一行"实际上是否应该如此.

The "testNumber" variable is just my control variable to check that the passed in uniform "rows" is actually what it should be.

一些统一的行"给出了奇怪的行为.下面是将其设置为9.0(并相应设置了testNumber)的示例.

Some numbers of the uniform "rows", gives a strange behaviour. Below is an example where it's set to 9.0 (with testNumber set accordingly).

预期结果.但是,将行设置为7.0(并相应地设置为testNumber),则如下所示:

This result is expected. However, setting rows to 7.0 (and testNumber accordingly), it looks like this:

很明显,有些事情没有按预期进行.有什么想法吗?我试图将精度设置为lowp,medium和highp,没有任何区别.

Clearly something is not working as it should. Any ideas why? I have tried to set the precision to lowp, mediump and highp without any difference.

谢谢

推荐答案

这可能是不精确的浮点数学的结果,该数学遵循

This is likely the result of imprecise floating-point math, which adheres to rules documented in the GLSL ES Specification. The highp qualifier guarantees that the inputs and outputs of the mod operator are 32-bit IEEE 754 floating point numbers, but the calculation itself is not guaranteed to produce the same high precision. In particular, the modulus operator is defined in Chapter 8.3 as

genType mod(genType x,genType y)

genType mod (genType x, genType y)

模量.返回x – y *底数(x/y).

Modulus. Returns x – y * floor (x/y).

此表达式中的除法运算符 a/b 保证对 b 具有不小于2.5 ULP的精度(请参见第4.5.1章),通常为计算为 a *(1/b),因为倒数和乘法比除法便宜.在您的情况下, 1/testNumber 是一个编译时常量,其计算精度可能不同于 1/rows ,后者需要在运行时进行计算时间.

The division operator a/b in this expression is guaranteed to have a precision of no less than 2.5 ULP for b (see chapter 4.5.1) and is typically computed as a*(1/b) since reciprocals and multiplications are cheaper than divisions. In your case, 1/testNumber is a compile-time constant and is probably computed to a different (higher) precision than 1/rows, which needs to be computed at run-time.

您可以尝试使用整数数学而不是浮点数,因为整数模运算符 a%b 不会遇到此类精度问题.

You could try using integer math instead of floating point, as the integer modulus operator a%b doesn't suffer from such precision issues.

这篇关于WebGL浮动模量行为的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆