Add support for property attribute property styling

[j9liu]

Feature

Currently we don't support access to property attributes, nor the styling of them. It shouldn't be too much of a lift to add support for FCesiumPropertyAttribute and FCesiumPropertyAttributeProperty. This would also simplify a lot of things for #1685, so I'm tempted to just do this off-the-bat.

Property attribute styling is less straightforward. 😕 There isn't an easy way to pass custom vertex attributes to Unreal materials without writing a custom vertex factory / shader (which is a lot of effort), and also isn't dynamic to work with the same way that Unreal materials are. Some options are...

• Attempt to pass properties through unused UV channels. We already do this for per-vertex feature IDs. However, metadata properties are more arbitrary, so we could have something like vec4 properties which would take up 2 full UV sets. There is a hard limit on the number of properties we could support because we could only pass up to 16 scalar values, and this space is further compromised if the model comes with its own UV coordinates.
• Copy what we did for property tables. Upload the entire attribute buffer to a texture, and then access the values by index. The vertex index must be stored in a UV channel because there is no "Vertex Index" node in Unreal material graphs, but it only takes one UV channel to enable an arbitrary amount of properties.

The latter seems best for the most immediate value and reliability. I think in that case, it also wouldn't be too much of a lift.

[j9liu]

API Design Nitpicks

In the glTF's top-level EXT_structural_metadata, a property attribute just maps each property name to the attribute ID it should look for in the glTF, e.g.:

"propertyAttributes": [{
        "class": "movement",
        "properties": {
          "direction": {
            "attribute": "_DIRECTION",
          },
          "magnitude": {
            "attribute": "_MAGNITUDE",
          }
        }
      }]

Then, a glTF primitive's EXT_structural_metadata specifies the indices of the property attribute that it uses:

  "primitives": [
    {
      "mode:": 0, 
      "attributes": {
        "POSITION": 0,
        "_DIRECTION": 1,
        "_MAGNITUDE": 2,
      },
      "extensions": {
        "EXT_structural_metadata": {
          "propertyAttributes": [0]
        }
      }
    }
  ]

This makes the API a little awkward for FCesiumPropertyAttribute. The spec suggests that it should live at the model level. However, a FCesiumPropertyAttributeProperty would have to be constructed with a glTF primitive to actually get data via its attributes. This differs from property tables / textures, where the data lives at the model level in some disconnected buffer or texture.

If we mirrored the spec for symmetry and made FCesiumPropertyAttribute live in FCesiumModelMetadata, it wouldn't be too useful. It couldn't immediately store any FCesiumPropertyAttributePropertys, so there would have to be a function to actually map its properties to a given glTF primitive's attributes (e.g., GetProperties(UPrimitiveComponent* )). But since it doesn't provide any initial data like FCesiumPropertyTable or Texture, it's kind of useless to store. Returning the attribute names won't be useful to the user when there's no way in Blueprints to access a glTF's attributes in the first place.

I'd argue it would be simpler to deviate from the spec and instead store the FCesiumPropertyAttributes in FCesiumPrimitiveMetadata. Instead of FCesiumPrimitiveMetadata storing indices of FCesiumPropertyAttributes that live on FCesiumModelMetadata, this instead folds the FCesiumPropertyAttributes into an array on FCesiumPrimitiveMetadata. So I'm going to do it this way 🙂

[j9liu]

#1694 has been merged, but styling is still unsupported.