I’m new to 3D geometry and WebRendering of 3d objects.
So, I came across a glTF to 3d Tile converter which seems to be taking up a lot of space post conversion. I don’t exactly understand the reason for the inefficiency and this library accepts only Embedded glTFs.
It would be appreciated, if someone can help me optimize the library and provide any insights on how to make it efficient. Or, any other library which is efficient and useful for my use case, as I will be rendering it on CesiumJS.
It is not entirely clear what the goal of the conversion is.
When you have a large and complex glTF asset, and want to convert it into a 3D Tiles tileset so that it can be streamed to clients efficiently, then you can upload it to Cesium ion – Cesium - it will do all the tiling and optimization work.
The library that you linked to does not seem to do anything like this. It looks like it is mainly generating a tileset.json file for a given input. (And… if it only accepts embedded glTF assets, then this is probably not ideal: Embedded assets usually have a considerable overhead in terms of the file size. In most cases, you should use a GLB). The task to generate a tileset.json for given tile content has recently also been requested in the 3D Tiles tools repository, and there is a draft PR with that functionality at Generate tileset JSON from content files by javagl · Pull Request #51 · CesiumGS/3d-tiles-tools · GitHub - maybe you want to give it a try.
We are building a product with open source libraries, hence Cesium Ion is out of the picture. The goal of the conversion is to load big gltf models in cesiumJs.
I did tryout tileset-json-creation branch from 3d-tiles-tools, It is creating a tileset for provided input glb file, but just wanted to understand, if the glb file is huge and complex how and on what basis we have to slice the glb file, so that we can load the tileset based on the camera’s perspective.
It is creating a tileset for provided input glb file, but just wanted to understand, if the glb file is huge and complex how and on what basis we have to slice the glb file, so that we can load the tileset based on the camera’s perspective.
Yes, this command-line functionality is only intended as a small convenience tool for people who quickly want to “wrap” a tileset.json around an existing glTF asset, without having to do things like the bounding box computation manually.
When you talk about a “huge and complex” GLB file, and the goal of visualizing that “based on the camera’s perspective”, then this sounds like task that has to be done by a tiler.
There could be “simple” approaches for “simple” inputs that may already yield useful results. For example: One could take the glTF asset, and put each mesh (or each mesh.primitive) into its own glTF file, and then combine these glTF files into a single tileset JSON. This would already allow you to load parts of the tileset, based on the viewpoint. But … what if there is only one mesh? Then the mesh geometry has to be split into multiple parts. This can already be tricky. And if the mesh is very complex, then you’d not only like to split it into multiple parts, but also simplify the mesh and create a LOD hierarchy…
I cannot give any recommendations for open-source libraries for this task, because there are too many degrees of freedom for the type and structure of the input data, too many degrees for optimization of the output data, and too many factors (and engineering questions) that affect how to most sensibly produce good 3D Tiles tilesets.
I’m not sure whether this a technical or “legal” question. But the cesium-native repository is open source, published under the Apache-2.0 license, and can be used (via CMake) in any C/C++ project.
The CesiumGltfReader and Cesium3DTileWriter libraries could be small building blocks for such a conversion.
With the CesiumGltfReader, you can read glTF assets and receive them as the data structures that are defined in the CesiumGltf library. And you can create new glTF assets using these classes, and write them into files with the CesiumGltfWriter (these could basically be the “tile contents”).
With the Cesium3DTiles library, you can build a 3D Tiles tileset in memory, and with Cesium3DTileWriter, you can write these structures to files (to eventually create the tileset.json).
But note that “reading input data” and “writing output data” are only very tiny fragments of a proper tiler. The process of subdividing and simplifying the geometry data that was read from the glTF would be the most challenging part here (and you’d probably create a library with custom data structures for that, depending on how sophisticated that is supposed to be).