Hi, I’m trying to use Cesium Ion as part of my own custom engine to stream and render 3D tiles of the Earth (as .gLTF models), based on the camera(position / near / far / FOV etc).
I was hoping there’d be an API endpoint or utility of some sort that can take in my camera’s information and return a list of URLs pointing to the relevant .gLTF models that are in view, along with where they should be placed in world space, or something to that effect.
It seems based on this graphic:
That Cesium Native is what’s mostly used by other engines to manage the streaming of tile data, and CesiumJS is a combined library that handles both the streaming and rendering.
I have been toying with CesiumJS, recursively adding event listeners to try and maintain a list of loaded / unloaded tiles and trying to get their respective meshes. I can’t seem to actually find URLs to these meshes though, they all point to other JSON files or to .b3dm files, and I can’t find where each should be rendered in world space.
As my engine compiles down to the web, I could interface with CesiumJS directly if need be, if there’s a simple way I could give it information about my camera and have a stream of .gLTF models returned that I can pass to my engine. Likewise, if there’s a simpler way of doing this using something in Cesium Native and passing its results back to my engine, I’d love to hear it.
Thanks 
Hi,
Welcome to the Cesium Community!
Cesium ion does not currently expose an endpoint that provides a set of GLTF files based on a camera view. If you wanted to build something on your own you could start with the asset endpoint route. That would get you a way to access the tileset.json file. You would have to parse that out to get the bounding volumes of the tiles and then do the computation for which ones were inside your view frustum. That would let you know which content to load. Also the content files may not always be GLTF files. CesiumJS and Cesium Native do this as part of their 3d Tiles rendering.
Are you able to provide any additional information about why using CesiumJS or Cesium Native to render the 3d tiles is not a good solution for you? If you can provide more details about your use case, we might be able to recommend a way for you to accomplish what you need using CesiumJS or Cesium Native.
Hi,
Thanks for the detailed reply!
I see, so CesiumJS / Cesium Native both handle what requests to make to the API based on the camera as I suspected, and if I query the API directly I will have to handle finding which tiles are in my camera’s view myself. I’ll look further into that asset endpoint, thanks.
As for more information, I already have my own custom engine written in Rust using wgpu that I want to integrate Cesium into, specifically to render terrain and buildings. I’m rendering my own entities atop with a myriad of other custom functionality. Using CesiumJS directly would mean recreating my entire engine in a different language, which makes little sense. Cesium is just one part of many in this system.
I was thinking I could run CesiumJS (without a viewer) alongside my engine however, sharing the camera’s state between them and parsing out what tiles are loaded to pass back to my engine and render. This seems a roundabout route though when I can just call the API and figure out viability myself.
Are you already rendering 3D tiles in your engine? If not, I strongly advise you to look at cesium-native as the route to getting that capability. It’s written in C++ and I don’t know how much glue code you would have to write to access its return results in Rust. The representation of tile geometry is pretty similar to tinygltf.
That seems wise yeah, do you know of any particular C++ examples using cesium-native? The documentation for it seems pretty scarce. I’ve built it but making sense of it without examples is proving difficult.
I’m the author of vsgCs, which is a Cesium native client for the Vulkan Scene Graph library written in C++. I wouldn’t say that it is well documented, but it’s a lot simpler than the Unreal or Omniverse clients, for example.
