3d-tiles
3d-tiles copied to clipboard
CesiumGS
Time-dynamic 3D Tiles
As alluded to in the intro:
Cesium is designed for time-dynamic visualizations, such as of satellites and UAVs. The next step is to extend this to 3D Tiles so users can, for example, see topography or snow cover change over time with massive time-dynamic terrain and point clouds.
The may work like streaming video per tile: a tile contains data for a set of tiles and can be prefetched like streaming video. So a tile really has a set of physical tiles each with a subset of the times.
A clean approach could be to introduce a new TemporalComposite tile format similar to Composite that contains multiple time-tagged potentially heterogeneous tiles.
It could have pointers to past and future (in time) tiles - or - the tile in tileset.json could have a tree of time intervals that reference TemporalComposite tiles. Either way, the key is that multiple tile steps can be stored in one tile and past/future tiles can be prefetched. Different tiles in tileset.json can, of course, have different sets of time intervals.
For specific cases, e.g., points clouds, we can explore just storing the deltas, e.g., if per-point color remained constant over time, and just a delta position is needed for the next time step.
Adding use case here per our conversation on the forum:
We have thousands of points with billboards (MILSYM) that are being updated on an irregular basis (think worldwide flight data). We are currently using the entity API to display and update these points and we are running into performance limits. Time dynamic tiles seem like a clean solution to matching desktop application performance levels. Let me know if there is anything else you want to know about our use case.
The lazy functional approach I described in my comments on #90 is also well-suited here, using something like a functional-reactive style. One component of the context passed to the callback could be a simulation-time value. When you regenerate the root occasionally in response to events (e.g. timesteps), the rest of the tree will still only need to be regenerated on an as-needed basis. I suspect this would be helpful to @colek42's performance problems if the majority of the billboards being updated aren't visible most of the time.
Byte serving could be an interesting case, where the hole tile contains all data and may be several mb large. Then maybe having a seperate index file or the first part of the file has the index.
Then the client could request the index part, and from there decide which range requests to do to get data for a specific time interval.
I think this is much like .mp4 container format, where some of the first bytes contain the length of the metadata and then the actual data coming after.
@pjcozzi , cool - i did not know there was a need for cloud optimized geotiffs. I been using geotiffs over http get ranges with current tooling of gdal and normal gtiffs without problems already.
But sounds like its a good direction.
Whats your take, since i asked here the other day https://groups.google.com/forum/#!topic/cesium-dev/JiTff4W5Gw4 and hoped it was already here. How is this priotized acording to other items, when would be a good time for me to plan my demo project if i want to wait for some time-dynamic 3d tiles. (I wont hunt you for giving me a wrong day, just to have an idea).
Hi, For the record, we (LIRIS Lab in Lyon, France) are working on extending 3D Tiles for managing spatio-temporal features (using the new extras and extensions mechanisms). We are currently finishing a paper on this subject and we will then provide examples in open access. I'll come back with more information whenever it's fully ready :)
This CesiumJS PR adds a per-tile availability range: https://github.com/CesiumGS/cesium/pull/8488 - an approach to consider for 3D Tiles Next.
