Warp/composite mesh U/V coordinates cause issues with some preset shaders about projectm HOT 4 CLOSED

The following intrinsics have a limited domain where their output is defined and meaningful. Documentation for both HLSL shader model 3 and GLSL say that the output of sqrt(x) where x < 0, for instance, say the output is NaN. However, in reality this function returns sqrt(abs(x)) if x < 0 in DX9's shader model 3 implementation. This has been verified using BeatDrop 1.3.1 after installing DX9 (note that BeatDrop requires DX9 specifically; otherwise you'll get errors about shader model 3 being reported as supported but non-functional).

By creating a shader that plots the output of these intrinsics, we can easily verify the behavior of each intrinsic. Here are the presets I used to plot these intrinsics. The R+G channels plot the unmodified intrinsic. The B channel plots the modified function to be used in projectM. If the plot has no yellow or blue regions, these functions overlap perfectly.

math_presets.zip

The functions include:

• acos: Defined only on the range [-1,1]. Shader model 3 appears to implement this using hyperbolic functions (this is just a guess) that remain valid outside of this range, but the equation is unknown. In an attempt to qualitatively replicate this behavior in GLSL, I've created a simple polynomial function and piecewise extended the function outside of the range [-1:1].
• asin: Same as the acos implementation. The same polynomial is used to mimic the SM3 behavior.
• pow: This function actually behaves identically in HLSL and GLSL. If the first argument is negative, the output should be NaN according to the documentation. The actual output is pow(abs(x),y) unless y is actually a constant integer, in which case the result is actually x^y. Note the difference in behavior between pow.milk and pow_constant.milk in the attached presets.
• rsqrt: The inverse square root is defined on the range [0,inf). SM3 appears to take the absolute value before taking the inverse square root, so this is replaced with rsqrt(abs(x)) in GLSL.
• sqrt: Same as rsqrt.
• log, log2, log10: Same as rsqrt; shader model 3 appears to take the absolute value of the argument before taking the logarithm (note I forgot to include the log presets but you can easily create them).

The trigonometric functions are not perfect, but qualitatively mimic the shader model 3 implementation until the actual function can be found:

The sqrt and rsqrt functions clearly show the abs behavior:

from projectm.

Note this isn't directly related to issue #725. While the other issue fixed some now superfluous negations in the u/v coordinates of the warp mesh, the issue here still remains unsolved.

from projectm.

@dpw13 has identified the issue to be undocumented, undefined and unexpected behavior in HLSL, causing some math functions like pow, sqrt and log to produce results even with negative input values, which - according to the HLSL documentation - should return NaN or Inf, but in reality seemingly take the absolute value of the parameter in question and thus return some kind of mirrored value.

Dane is fixing it in the hlslparser by adding abs() around the problematic parameters to make the shader behave in a similar fashion.

from projectm.

There still are issues here and there, but the major part is done. Anything else, we'll fix over time - that is, if it's possible.

from projectm.