CesiumGS / CesiumGS/cesium-native
Handling time in Cesium Native and the native runtimes
- Dominant language
- C++
- Stars
- 623
- Forks
- 277
- PR merge metrics
- No merged PRs in 30d
Description
We've gotten surprisingly far in Cesium Native without support time-dynamic data, but I wanted to start thinking about it with [time-dynamic 3D Tiles](https://github.com/CesiumGS/3d-tiles/issues/102) on the mid-term roadmap.
Supporting time in Cesium Native would allow us to support:
* Vector formats like CZML, KML, GPX
* Raster formats like [WMTS + Time](https://sandcastle.cesium.com/?src=Web%20Map%20Tile%20Service%20with%20Time.html)
* [Time-dynamic 3D Tiles](https://github.com/CesiumGS/3d-tiles/issues/102)
* glTF animations
At a high level this might look like:
* A `CesiumTime` library with core classes like `Clock` and `JulianDate` ported from CesiumJS
* A mechanism for converting game engine / system time to Cesium time
* Passing time to `Cesium3DTilesSelection::Tileset::updateView`
* Game engine-specific widgets like clock and timeline
@kring I'm curious to hear your thoughts. I'm sure it's been in the back of your mind since the start of Cesium Native and Cesium for Unreal.
Contributor guide
Research direction
No implementation files or tests are identified. Start by reviewing Cesium3DTilesSelection::Tileset::updateView and the existing native runtime boundaries, then compare the proposed CesiumTime concepts—Clock and JulianDate—with the listed CZML, KML, GPX, WMTS, 3D Tiles, and glTF use cases. Done would require an agreed design and coordinated support across the relevant runtimes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- computer-graphics, game-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100