# Standard guidelines for exposing Metadata API **URL:** \ **Category:** 3D Tiles for Godot\ **Created:** [May 26, 2025, 6:14pm UTC](https://community.cesium.com/t/standard-guidelines-for-exposing-metadata-api/40928 "2025-05-26T18:14:12Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![GeorgeS2019](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/georges2019/32/13771_2.png) [@GeorgeS2019](https://community.cesium.com/u/GeorgeS2019)\ **Post date:** [May 26, 2025, 6:14pm UTC](https://community.cesium.com/t/standard-guidelines-for-exposing-metadata-api/40928/1 "2025-05-26T18:14:12Z")
Different game engines have established user friendly metadata API to optimize the exploitation of what Cesium has been designed to empower users. Godot for Cesium is a new addition to the family of Cesium values for the worldwide users. It would be prudent that there are guidelines how: [1] What are the minimum first stage exposure of Metadata API which are the minimum API that would allow visualiation in Edit mode (e.g. in Godot) [2] Which are the next level beyond the basic Metadata API for users to be aware of location, surrounding buildings and their attributes and street etc. [3] What are the bleeding edge advanced Metadata API that are being developed by more matured game engines e.g. Unreal in exploiting the API =\> We need these guidelines so we can evaluate if the path of Godot for cesium development is on the right track serving Godot communities as was the vision of allocating grant and resources for making Cesium available (urgently) to the Godot communities. I value any developers from other game engines e.g. Unreal and Unity for sharing your experience. What should users from Unity and Unreal expect these API in Godot. > ---
**Author:** ![George\_L](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/george_l/32/30054_2.png) [@George\_L](https://community.cesium.com/u/George_L)\ **Post date:** [December 3, 2025, 4:14pm UTC](https://community.cesium.com/t/standard-guidelines-for-exposing-metadata-api/40928/2 "2025-12-03T16:14:54Z")
[TileMetadata.h](https://github.com/Battle-Road-Labs/3D-Tiles-For-Godot/blob/master/cesium_godot/Models/TileMetadata.h) ![image](https://global.discourse-cdn.com/cesium/original/3X/6/4/6456f62a2f9a23969e826e780e820a7369f25bb6.jpeg) # Comparison of Unity granular feature metadata system and Godot Cesium metadata API * * * ## High-level differences | Aspect | Unity granular system (Cesium for Unity) | Godot Cesium API (code provided) | | --- | --- | --- | | Feature ID sources | Separate implementations for vertex attributes, textures, and implicit IDs via CesiumFeatureIdAttributeImpl, CesiumFeatureIdTextureImpl | No explicit feature ID source abstraction; focuses on property table parsing via CesiumGltf::PropertyTableView | | Property access model | Strongly typed property wrappers (CesiumPropertyTablePropertyImpl) with centralized coordination (CesiumMetadataImpl) | Properties normalized into Godot Dictionary and Variant via CesiumPropertyInfo and EPropertyType/EComponentType | | Value typing and conversion | Dedicated value layer (CesiumMetadataValueImpl) optimizing type coercion and performance | Template-based mapping to Variant, with enums for type/component and warnings for narrowing conversions | | Extensibility | Modular implementations per metadata source; behavior can be extended or overridden per type/source | Centralized conversion path; extensibility requires altering template helpers or adding new EPropertyType/EComponentType cases | | Performance strategy | Source-specific optimizations; avoids unnecessary allocations; type-safe access paths | Conversion to Variant and Dictionary for engine interoperability; potential overhead and narrowing during float64→float32 | | Developer ergonomics | Strong separation of concerns, clear source-specific APIs, C#-friendly | Single entry point (TileMetadata) yielding engine-native structures (Dictionary/Variant), GDScript-friendly | > Summary: Unity emphasizes modular, source-specific metadata handling with strong typing and performance specialization, while the Godot code prioritizes a unified, engine-native representation via Dictionary/Variant for broad usability. * * * ## What the Godot Cesium API exposes - **Entry point:** - **Type system:** - **Value container:** - **Conversion helpers:** - **Runtime representation:** * * * ## Where Unity provides more granularity - **Feature ID sources:** - **Property table access and typing:** - **Value conversion layer:** - **Extensibility surface:** * * * ## Strengths of the Godot approach - **Engine-native ergonomics:** - **Clear vector and array handling:** - **Safety cues during conversion:** * * * ## Gaps relative to Unity and practical enhancements - **Missing feature ID source abstraction:** - **Dedicated value layer for performance:** - **Per-property wrappers:** - **Matrix support parity:** - **Enum typing and validation:** - **Batch access and caching:** * * * ## Example usage patterns and recommended wrappers - **Godot scripting-friendly accessor layer:** - **Feature ID integration path:** - **Type-safe property API:** * * * ## Personalized guidance for your workflow - **For visualization pipelines and large tilesets:** - **For GPU interop experiments:** - **For editor tooling:** ---
**Author:** ![George\_L](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/george_l/32/30054_2.png) [@George\_L](https://community.cesium.com/u/George_L)\ **Post date:** [December 3, 2025, 4:19pm UTC](https://community.cesium.com/t/standard-guidelines-for-exposing-metadata-api/40928/3 "2025-12-03T16:19:46Z")
> [@George\_L](#): > > [TileMetadata.h](https://github.com/Battle-Road-Labs/3D-Tiles-For-Godot/blob/master/cesium_godot/Models/TileMetadata.h) * * * ## To bring **Godot’s Cesium TileMetadata.h** closer to the **granular, modular system Unity uses** , need to break out responsibilities into specialized classes rather than funneling everything through `TileMetadata` + `CesiumPropertyInfo`. Here’s a structured list of changes and additions: ## 🔑 Proposed Class Additions for Granularity ### 1. **Feature ID Sources** - **`FeatureIdAttributeSource`** - **`FeatureIdTextureSource`** - **`FeatureIdImplicitSource`** * * * ### 2. **Property Wrappers** - **`PropertyTableProperty`** * * * ### 3. **Value Layer** - **`MetadataValue`** * * * ### 4. **Metadata Coordination** - **`MetadataCoordinator`** * * * ### 5. **Utility Functions** - **`MetadataUtility`** * * * ### 6. **Matrix & Enum Support** - **`MatrixPropertyHandler`** - **`EnumPropertyHandler`** * * * ## 🛠 Structural Changes to TileMetadata.h - **Refactor `TileMetadata`** into a **facade** : - **Introduce caching layer** : - **Add accessor API** : * * * ## 📊 Comparison Snapshot | Unity Granular System | Godot Current | Proposed Godot Additions | | --- | --- | --- | | `CesiumFeatureIdAttributeImpl` | None | `FeatureIdAttributeSource` | | `CesiumFeatureIdTextureImpl` | None | `FeatureIdTextureSource` | | `CesiumPropertyTablePropertyImpl` | `CesiumPropertyInfo` | `PropertyTableProperty` | | `CesiumMetadataImpl` | `TileMetadata` | `MetadataCoordinator` | | `CesiumMetadataValueImpl` | Template helpers | `MetadataValue` | | `CesiumFeaturesMetadataUtility` | Inline templates | `MetadataUtility` | * * * ## 🎯 Outcome By modularizing into these classes: - **Granularity** : Each metadata source/type is handled independently. - **Performance** : Typed accessors and caching reduce Variant overhead. - **Extensibility** : New metadata forms (colors, packed bitfields, GPU pathways) can be added without touching core. - **Developer ergonomics** : Typed wrappers for C++ performance, Dictionary/Variant for GDScript prototyping. * * *