Shader styling considerations

[lilleyse]

Point cloud styling engines may often use a shader implementation. Currently the spec is written with a bias towards JavaScript and its implicit type conversions and ability to check equality between different types, which are not possible in a language like GLSL 1.0. Shader implementations will also have major issues with strings and regular expressions. We need to decide what aspects of the styling language can be supported for stricter languages like GLSL and C++.

• Shader Styling
  • Unsupported:
    • isNan, isFinite(supported in later versions of GLSL with isnan and isinf)
    • Strings, not supported in the GLSL styling engine or the batch table binary
      • This includes accessing color components like color()["r"] or vectors with vec4(1.0)["x"]
    • Regular expressions
    • Arrays that aren't length 2, 3, or 4 (technically supported but cumbersome to use)
    • null and undefined - use a default value like 0? Extend Sytling to allow check for existing of a property cesium#4637
    • type mismatching - comparing floats to bools to vectors will result in shader compilation errors
    • Index out of bounds for arrays/vectors/colors will result in shader compilation errors whereas it returns undefined in JS

More discussion here: CesiumGS/cesium#4336 (comment)

[pjcozzi]

To scope this for 1.0, I think we can just add some Implementation Notes like the glTF spec.

[ggetz]

Resolved in #301