Does anyone know if someone is working on a 3D Web Tiles loader for Three.js? We currently use the glTF loader by @donmccurdy et. al., and it’s great, but we’re moving into larger models, and it seems that 3D Web Tiles is becoming an accepted standard. We’d like to spearhead this effort if no one has taken it up yet, and if it makes sense to do so.
I haven’t heard of anyone working on this. It would be great to have a 3D Tile loader for three.js though, it looks like this format would fill a big gap in the current capabilities of the library when it comes to loading huge models/datasets.
Going over the spec now, I can see that glTF format is used internally for storing models, except for point clouds since they are not currently support in glTF. So the 3DTileLoader could use the glTFLoader for most of it’s heavy lifting. Point clouds seem to be defined using a custom format, but perhaps the PCDLoader could be used or adapted for those.
Aside from that, it seems like the main purpose of the format is to define a spatial index containing hierarchical level of detail info, so that the renderer can switch between different levels of detail based on some criteria (I don’t think those criteria are defined in the spec). Hopefully the three.js LOD object would be up to the task there for models. Probably point clouds would need special treatment.
The format also defines instanced meshes (also stored as glTF). I’m not aware of any three.js loaders that create instanced meshes, so that would have to be developed from scratch.
Bounding volumes for the tiles are defined using quadtrees (for models spread out over 2d maps), and octrees (for general 3D models divided up into parts). These are used to select the LOD at which to display the models. I’d have to investigate further, but it looks like it should still be possible to use the three.js scene graph for holding the objects, and just use the quad/octtrees for choosing the LOD. On the other hand, it might end up being more efficient to use octtrees all the way through. Not sure how much complexity that would add.
Overall, from a quick glance through the spec, I’d say that this is very doable, although it’s a pretty big project, and it’s going to be complex enough that the loader probably won’t fit into the main three.js repo. This is more of a “metaformat” than a standard 3D exchange format. At least the first stages of development would be better kept in a seperate repo.
Thanks for the thorough response.
I was pretty sure this wouldn’t go in the three.js repo. It is, as you say, too big. In addition to just the loading infrastructure there’s also stuff like camera controls which do selective loading. And I don’t know if people regurlarly use a web worker for the glTF loader, but this definitely would need workers for tile loading.
I actually didn’t know that Three had LOD meshes. But I’m not sure I’d use them here. My naive assumption was that I’d load/unload each tile as a root object with children or as a group.
I’d suggest keeping an eye on loaders.gl for 3D Tiles support:
It’s framework-independent, and may be a good option to build on.
1 Like
Great recommendation. Thanks!
That tends to be very slow. Generally, setting object.visible = true/false causes much less jank.
This looks very promising
2 Likes
That’s a project I worked on – thanks for posting @Julian_Ramirez_Ruiseco! There are a few more things I plan to address and then I’ll make a more detailed post here.
It only supports B3DM tile formats right now because that’s all we’re using but if anyone needs other 3DTiles features that aren’t supported yet I encourage you to make an issue or contribute back!
We’re planning to use it for an upcoming mission and it includes a couple extra features that enable it to skip unused parent tiles and load up to the correct level of detail more quickly.
It doesn’t process the GLTF files in web workers but it could be extended to do so. I question how much you’d gain from that, though, considering the model has to be serialized and deserialized again to transfer. The biggest load hiccup I saw was with texture decoding which can be helped with ImageBitmap loading.
3 Likes
Hey gk.
The work here is absolutely great. I took some time to go through the structure, and do a bit of speed testing.
I am going to introduce this to my production blast design software, and see how it performs with our webassembly bvh tools.
I will let you know once it’s in.
Thank you for making this. My guess is that this will make a major splash once more people begin finding it.
The work here is absolutely great. I took some time to go through the structure, and do a bit of speed testing.
Thanks! How did you do speed tests? I’ve created benchmarks for projects in the past but haven’t made them for this one. If you have a good approach it might be nice to include something like that in the repo.
I am going to introduce this to my production blast design software, and see how it performs with our webassembly bvh tools.
What types of BVH tools are you using? The 3d tiles library is using the existing bounding hierarchy to improve raycast performance and only raycast against tiles that are needed, but using a triangle BVH could be helpful per mesh. In the interest of sharing more overlapping work I’ve put together this three-mesh-bvh library to enable fast raycasting and intersection of meshes which can now be generated in webworkers though there’s no example of that yet.
Thank you for making this. My guess is that this will make a major splash once more people begin finding it.
I think the hurdle here is generating or getting a hold of 3d tiles data sets in the first place – it’s not necessarily straight forward to create and most of the other available data is from Cesium and locked behind an account and API keys (which is understandable). I am hoping to make more data of our own available at some point.
If you can share I’d be interested in seeing how you’re using 3d Tiles but at least I’ll look forward to hearing how it’s working for you. If there are improvements you need I’d be happy to work together to get them into the project!
1 Like
Any chance you could do a PR with this loader? I happen to have some assets that can be included in the repo 
1 Like
Unfortunately I think it’s a bit complicated. I’m not super excited about maintaining an up to date copy of the 3d tiles project in the three.js repo. It’s also using a slightly different license (Apache 2.0) from three.js and includes some extra license copy from Caltech JPL (which I’m working on).
I’d want to talk about the funder for the project, too – because while the project is open and anyone can use it anyone I know that organization is interested in building more of a presence in the open source space. As much as the intent may be otherwise I feel that once a piece of code is included in the three.js codebase that seems to become it’s canonical source and people see it as part of the library. It’s where people use it from, submit issues for it, and make PRs for it. I don’t believe I’ve seen a three.js example be maintained successfully outside of the repo (see LWOLoader).
I think my preference would be to see a reference to external projects in the docs like I suggested in issue #19353 to help bolster more community projects around three.js.
If you have data you are willing to share would you consider putting it in a separate repo? I’m definitely interested in more test cases. From the 3d tiles page we could display it via a githack link or something. Of course we can also include it in the 3d tiles repo itself but I’d understand if you have hesitations about that.
2 Likes
Sounds good! I’ll get back to you regarding the data.
Seems like the assets they were talking about were the official ones.
They made them CC0 last month btw.
1 Like
Thanks! I’ve seen these and have been using them to test against some official examples but they’re pretty basic and more or less just there to verify spec conformity (which is useful!). A lot of the interesting datasets from Cesium are now locked behind a Cesium Ion account and subscription which is too bad but understandable.
1 Like
Here’s another three.js library for viewing 3DTiles : https://github.com/ebeaufay/3DTilesViewer
I started it because the one from NASA wouldn’t handle some tileset tree structures and couldn’t handle nested tileset.json which is annoying for very large datasets. I hope it can help someone.
1 Like
If there are features or cases that the that 3DTilesRendererJS doesn’t handle please feel free to make an issue. One of the reasons some of these features are not implemented is because there have been no requests and / or I don’t have sample data. Bug reports are also appreciated. I can’t address any problems in the implementation unless I know about them.
1 Like
Here is one I was building from the ground up until I got busy with other things.
Three.js TypeScript Tutorials by Sean Bradley : https://sbcode.net/threejs
I’m going back to the drawing board on it. It’s not open source yet, and I’m not finished.
1 Like
Sure, I don’t want to criticize. It was simpler for me to have control over the code and I feel it’s good to have several options in open-source. It’s the opposite idea of one huge company making the perfect product which is never perfect anyways.
1 Like
By the way, maybe I can help with sample data. I have a library for converting unstructured meshes to multileveled 3DTiles so I can generate some if you need it.