-
Notifications
You must be signed in to change notification settings - Fork 470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time-dynamic 3D Tiles #102
Comments
A clean approach could be to introduce a new 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 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. |
Thanks for the use case, @colek42. |
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. |
Perhaps HTTP Byte Serving will be useful. |
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. |
@pksorensen agreed, also see Cloud optimized GeoTIFF. |
@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). |
Sorry I do not have any dates on this, but updates will be posted here. |
Hi, |
@jailln cool, looking forward to it! |
This CesiumJS PR adds a per-tile availability range: CesiumGS/cesium#8488 - an approach to consider for 3D Tiles Next. |
Also see TileDB which which has support for sparse data and time dynamic data. CC #580 (comment). |
As alluded to in the intro:
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.
The text was updated successfully, but these errors were encountered: