I use Cesium - Blank 3D tiles Tileset to add my tileset.json from C drive. However, How can I add more than a hundred json files in one go? Is it necessary to do it in script?
You have a hundred different tilesets with their own tileset.json? Yeah I guess you’d want to do that from script, then. Tilesets are usually meant to be chunkier than that, though. Having a hundred of them is very much not typical, and may lead to poor performance.
Thank Kevin. Should I merge all tilesets to one big tile before I add it to UE? But I can only download json format from web, not sure can it be easily to merge all together.
Where did you get these tilesets from? Merging them together in a way that achieves good performance is unfortunately not trivial.
I download from government public website, they provide the whole map but divided as many grid size tiles. Also, when I added to the UE, the error occurs: LogCesium: Warning: [2023-05-24 11:37:15.236] [warning] [TilesetJsonLoader.cpp:428] Tile did not contain a geometricError. Using half of the parent tile’s geometric error.
They provide them in 3D Tiles format? Or they provide some other format, and you converted them to 3D Tiles?
They provide 3D tiles format.
Hmm well I’m afraid they’ve missed the point of 3D Tiles there. It doesn’t make much sense to divide a model up into a grid of separate 3D Tiles tilesets. A single tileset has its own hierarchical tile / level of detail system that is optimized for visualization. A hundred tiles on a 2D grid is not useful for this use-case and forces a client to do a lot of unnecessary work.
Hi Kevin,
Probably these tilesets are produced on a per-capture/processing stage basis, and each tileset is delivered for a contiguous area of interest - since they are captured and processed independently, then each is dataset is delivered as a single 3Dtiles tileset.
A few related questions for my own understanding: The CesiumGS/3d-tiles-tools repo has merge and combine utilities.
- How are
combinevsmergedifferent? - Is one of these adapted to merging non-overlapping tilesets (eg what the OP mentions, arranged on a 2D grid)? Would be almost ok performance-wise when a single tileset fits within viewport, and only consider a few tilesets near the boundaries connecting two tilesets - but not very good performance for overlapping tilesets.
- and finally, is one of them meant to merge overlapping tilesets - therefore creating a completely new hierarchy with new tiles leaves merging tiles from the original tilesets? Such a behavior would then completely remove the burden on the client side which would do the smallest number of computation for a given viewport, since it would handle a real single tileset.
Thanks a lot for your help!
Edit: seems like
-
mergecreates atileset.jsonfile and copy-pastes all referenced tiles content (json+b3dm) of each input tileset to the output merged tileset directory - which some might want to disable if one only wants to reference the input tilesets, feature requested -
combinemight be the utility meant to reference tilesets from externaluri, but some older tilesets do have anurlproperty instead, so again, feature request to support these in case it is not possible for the user to upgrade the tilesets.
It sounds like Marco is answering your questions about 3d-tiles-tools, probably better than I could.
But I think it’s important to point out that neither this merge or combine will create a particularly efficient tileset in your case. It’s not overlapping versus non-overlapping that matters, but rather than you’re left with a bunch of parts all of which must be rendered. Let me explain what I mean.
Let’s say you have a 10x10 2D grid of tilesets. That’s 100 distinct tilesets in total. You can use 3d-tiles-tools to merge them into one logical tileset, but what you end up with is a single node in a bounding volume hierarchy which has 100 child nodes. If we’re zoomed out such that all of the grid cells are in view, all 100 of these tilesets must be rendered.
What you really want us a lower-detail representation with only 25 tiles, and another with 12, and another with 6, and so on. These lower-detail representations would cover the same area, but we use fewer vertices and triangles because they’re meant to be viewed from afar. This is fundamentally how 3D Tiles is meant to work.
Even in a horizon view, some of the grid cells are nearby while some are far away and would be better rendered in a low-detail form combined with their neighbors.
Unfortunately there’s no easy way to do this, and it’s not something that 3d-tiles-tools does out of the box. One approach that may work is to combine all the tilesets into a single giant glTF, and then let Cesium ion tile it all together. This may become prohibitive if the models are very large, though.
1 Like
Hi Kevin,
Thanks a lot for your feedback and illustration, very useful.
I understand the hierarchical structure of 3d-tiles, and you are right that for such high tilesets counts, even if the viewport and accepted pixel error makes it so that “for 90% of the tilesets, only the root tile would be displayed”, then it would still have to render all these 90 tilesets root tiles, as well as all the tiles required to render for the other 10% of the tilesets (which would require more than only their root).
I had some hope that either the merge or the combine utility from 3d-tiles-tools would handle these cases. Rigth now, I’m not exactly sure about the difference between these two tools.
By the way, I’ve seen a Cesium3DTilesWriter classes in the cesium-native repo. Is it meant to offer the ability to convert any arbitrary input mesh to 3D-tiles at some point?
PS: Peregrinations regarding tilesets merging:
In the gridded example, this could incur:
- merging root tiles contents for all tilesets (the lowest level of detail for each tileset) which would have manageable polycount of
max_tile_polycount * tilesets_count, - applying tileset creation on the resulting merged mesh
- and in the resulting tileset, replacing leaf nodes by the respective tilesets with
"refine":"REPLACE"attribute.
Actually, with the above technique, there would be no way to make sure the leaves cover each a single tileset, so going the other way, bottom-up, merging tilesets if they are adjacent to each other would make more sense. But then finding the right procedure which could work for any set of tilesets would indeed be tricky.
By the way, I’ve seen a Cesium3DTilesWriter classes in the cesium-native repo. Is it meant to offer the ability to convert any arbitrary input mesh to 3D-tiles at some point?
It would be useful for developing such a tool (and in fact, we use it in our own), but we don’t intend to implement a full tiler in cesium-native anytime soon. Because, frankly, selling tools to produce content in open standards for use in our open source clients is part of how we fund development of those standards and clients.
1 Like
Thanks, perfectly understood - and indeed a services-based business model adopted by lots of companies working in the open and pushing the overall ecosystem of oss tools forward.
Hopefully a community effort will be pushed in that direction at some point to build an open-source meshes tiler for massive meshes - oslandia for example might have that as an end term goal with py3dtiles (although for ptc only atm).
Note for small-sized businesses which are data-hoarders like us, having a business option to tile on premise on our own machines rather than via a cesium ion subscription would be also very interesting - we do total ~300TB of data, ~300 scans of heritage sites, cities and monuments, of which ~10TB are of output 3D scans, so the current per GBs Ion tiers are not making sense from a business perspective yet.
Again thanks a lot for all your time replying to these comments.
Cesium sells products, we’re not a services business. One of our products is an on-premise version of our tiler suite. It’s the same set of tilers used in Cesium ion, but available for use on your own machines.
1 Like
Thanks for the note. Sorry I thought most of Cesium revenue came from services plus consultancy (either for private companies or public/gov and maybe extra institutions/orgs like OGC), as showcased in the wonderful work and platforms you’ve been sharing on social that were build on top of cesiumjs, eg with Komatsu in AEC industry, etc.
The only Cesium product I knew was Ion, with the tiler/storage/streaming capacity offered as a service via subscriptions plus a few additional utilities like Stories or Measuring tools. Good to know it is among the major sources of revenue for your team, that then helps you fund the whole massive geospatial 3D ecosystem and allocate time and resources for the oss format standards, viewer and 3D engines integrations etc!
Also, thanks for linking the On-Premises product, might be indeed a good fit for our use-case! Out of curiosity,
- what’s the largest poly/textures-count you’ve tiled with it?
- does it come with a way to merge tilesets (like a 1B tris covering a whole natural/urban landscape, with 10 different monuments as focuses, each 1B tris)?
- How would I handle iteration, like adding 5 new focuses a year later, without re-computing the whole master tileset?
I’m afraid I don’t know the answers to your questions about the tilers off-hand. You may find the on-prem documentation helpful:
Beyond that, you can use the contact form to get in touch with our sales folks:
They may have answers to these questions for you, or at least can arrange for you to trial the tilers yourself.
1 Like