Fix glTF voxel ordering for ellipsoid shapes

[jjhembd]

Description

#12432 updated Cesium3DTilesVoxelProvider to read from tilesets containing glTF tiles, conforming to the proposed update to the EXT_primitive_voxels extension. This included a change to the ordering of the input metadata, based on glTF conventions for the up-axis.

However, the updated extension did not change the ordering of the metadata for ellipsoid-shaped voxels, since the (longitude, latitude, altitude) ordering defines its own "up-axis" along altitude. #12432 did not consider the ellipsoid case, and therefore broke ellipsoid-shaped voxel tilesets.

This PR updates the logic to consider the metadata order for all VoxelShapeTypes. Along the way, the keys of the VoxelMetadataOrder enum were updated to the more explicit Z_UP and Y_UP, since GLTF does not really describe what is happening in each case.

I also updated the VoxelEllipsoid3DTiles sample dataset to make the orientation of the data apparent in the Sandcastle, so we can catch problems like this more quickly.

Issue number and link

Testing plan

Load the "Voxels in 3D Tiles" Sandcastle and verify that the colors render with the following correspondence:

• Red = longitude
• Green = latitude
• Blue = altitude

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @jjhembd!

✅ We can confirm we have a CLA on file for you.

[jjhembd]

@ggetz for the note in CHANGES.md, I listed this as a fix. However, it technically includes a breaking change, since we changed the keys of the public enum VoxelMetadataOrder.
Perhaps VoxelProvider.metadataOrder could be private? It defaults to Z_UP for non-3D Tiles voxels.

[ggetz]

Perhaps VoxelProvider.metadataOrder could be private? It defaults to Z_UP for non-3D Tiles voxels.

If it is part of a public interface, I don't believe we can make it private. However, we can remove it from the public interface and only implement it for Cesium3DTilesVoxelProvider.

Technically speaking, we should probably list breaking changes as such in CHANGES.md, even if (hopefully) not many users are depending on it yet.

[ggetz]

@jjhembd Code here is looking good! Let's just make sure to address the above comment, and this should then be good to merge.

Thanks for the quick fix!

[jjhembd]

we can remove it from the public interface and only implement it for Cesium3DTilesVoxelProvider

@ggetz I think this makes sense. I removed metadataOrder from the VoxelProvider interface and marked the enum as @private. This is called out in a "breaking change" notice in CHANGES.md.

[ggetz]

Sounds good to me! Thanks @jjhembd!