Handle undefined vector properties in styles better

[lilleyse]

Since #9882, missing properties in point cloud styles resolve to undefined instead of throwing an error. undefined is converted to the sentinel value czm_infinity. This works ok if your property is a scalar but if it's a vector there may be type mismatches which cause the shader to not compile.

For example if your point cloud is missing a "Velocity" property the second condition of this style will not compile because it will resolve to czm_infinity == vec3(0.0)

tileset.style = new Cesium.Cesium3DTileStyle({
  color: {
    conditions: [
      ["${Velocity} === undefined", "color('yellow')"],
      ["true", "${Velocity} === vec3(0.0) ? color('red') : color('blue')"],
    ],
  },
});

If your point cloud has a "Velocity" property but the style has an undefined check it will also fail to compile because the first condition will resolve to vec3(...) == czm_infinity

tileset.style = new Cesium.Cesium3DTileStyle({
  color: {
    conditions: [
      ["${Velocity} === undefined", "color('yellow')"],
      ["true", "color('red')"],
    ],
  },
});

The left hand side of the === could be a more complicated expression and it would be very difficult to detect the type. But if it were possible to detect the type you could convert the undefined to a vec3 of czm_infinity (for example) so that the types match. Another thought is to always promote each side of the === to a vec4, but this isn't possible with GLSL's vec4 contructors without knowing the type. Another idea is to keep trying to promote each undefined to the right type until the shader compiles, but this is impractical because of the number of permutations possible.

In general undefined is not the easiest concept to work when styles are transpiled to GLSL and I think 3D Tiles Next metadata and custom shaders with their stricter type safety will avoid such problems.