Consider combining `normalized/offset/scale` in `valueTransform`

[javagl]

A class property can have the following properties:

• name, description (metadata)
• type, componentType, enumType, array, count (structure)
• normalized, offset, scale (value transform)
• required, noData, default (usage)
• max, min ("value metadata"?)
• semantic ("usage metadata"?)

The grouping of these properties in the list above roughly corresponds to what I'd consider as "things that belong together", with "the thing that they represent" given in brackets. One could go very far with listing options about how these things could be modeled and represented. But one consideration is to combine the normalized, offset and scale properties into a single thing. This single thing could be called valueTransform.

---

An aside:

There are many trade-offs and considerations when it comes to the question about how to actually model things like this. This refers to the implementation (e.g. the JSON schema in 3DTILES_metadata). There sometimes are requirements or constraints that are only described verbally, in the description in the JSON schema, but hard to check structurally. And one of these requirements here is that offset and scale may only be present when normalized is true. One way of modeling this "value transform" structurally would be to ditch the normalized flag, and just say that the offset and scale of the valueTransform indicate the codomain of the value transformation, defaulting to offset=0,scale=1. Then, the presence of an (empty!) valueTransform: {} is the same as normalized=true. A structure like

valueTransform: {
    offset: 10,
    scale: 20
}

would map the source range of the value (whatever that is) to the range [10,20]. In any case, it would no longer technically be possible to have invalid structures with things like normalized=false,scale=10.

Would that be "better"? In some ways, and a technical sense: Yes. Would it be "nicer", along all the possible dimensions of the term 'nice'? That's open for debate.

[lilleyse]

Personally I find an explicit normalized property to be clearer. Also I'm not sure I would group normalized in the value transform category since I think of it as part of the type definition similar to normalized types in OpenGL and Vulkan like VK_FORMAT_R8_UNORM in that it defines the packed type and the unpacked type. That is up for interpretation though.

The valueTransform object could still be convenient for grouping offset and scale.

[lilleyse]

And one of these requirements here is that offset and scale may only be present when normalized is true.

offset and scale can also apply to FLOAT32 and FLOAT64 component types.

[javagl]

While I still think that combining things that belong together and giving names to these things is the right approach (and such a ValueTransform could have made sense), the 3D Tiles 1.1 specification is finalized in its current form, so I'm closing this for now.