Babylonjs renderer

[FreakTheMighty]

Is your feature request related to a problem? Please describe.

I'm looking for a 3D tileset renderer for Babylon.js. I've played a bit with loader.gl which seems focused on geospatial tilesets. While I see that this library is focused on three.js it also looks like the core is well separated from the three.js rendering portions of code. So, I just wanted to open a ticket to start the discussion about what it might look like to add additional renderer supports.

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

I may modify loader.gl to support non-geospatial tilesets and write a babylonjs extension for that library.

Additional context

My main content priorities would be

• gltf tiles
• b3dm tiles
• point cloud tiles

[gkjohnson]

Hello! Yes the project is split into two pieces - the src/base and src/three folders. The src/base does not rely on three.js at all and is designed to support other renderers as you're interested in. The src/three/TilesRenderer.js file should serve as a good reference for what needs to be implemented to extend the TilesRendererBase implementation.

In terms of where this belongs - I am not a Babylon expert nor user so I'm hesitant recommend that this extension should be added to this repo since it means I will ultimately be responsible for maintaining it unless someone is interested in triaging that side of the project longer term. I'm open to suggestions but I'm thinking a good first step is either a separate repo or implementing this as an examples/src/BabylonTilesRenderer.js file.

I'm also happy to take a look at and merge PRs that might be needed to the core project to help enable this work. It's also possible there are some pieces in the src/three directory that can be more generalized for further code consolidation. Let me know what you think.

[FreakTheMighty]

Thanks for the feedback @gkjohnson. I like the idea of creating a new repository that depends on this one. Would you need to make any changes are you end to support that?

[FreakTheMighty]

The first thing I'm noticing is that I get three.js as a dependency ... which makes sense. I'm guessing it'd be a bit of a project to pull the core out into its own library?

[gkjohnson]

Would you need to make any changes are you end to support that?

I don't believe so - everything needed from src/base should already be exported.

The first thing I'm noticing is that I get three.js as a dependency ... which makes sense

Three.js is a peerDependency so it shouldn't be automatically installed - though npm may complain. There may be a way to mark the dependency as optional that would be worth looking into if you have ideas, but it should be possible to install without three.js.

Even if you install three.js, though, most if not all modern bundlers will only use the pieces you import via tree shaking. If this turns out to be more complicated we can add an additional export option for just those core items.

[FreakTheMighty]

Currently I'm using an altered version of the loader.gl engine (I made some messy alterations to support non-geospatial use cases), but I'm not sure its the right direction for creating a library that the babylonjs community can jointly benefit and collaborate on. For that, I'm interested in further exploring how I can extend this library.

I've got the scaffolding for a babylonjs extension for this library, but I'm wondering if more of the three.js logic can be moved into the core.

Specifically I'm curious about the core of this library supporting the ability to:

• Query the tileset given a platform agnostic camera model
• Retrieve a list of content that needs to be downloaded
• Retrieve a list of tiles that should be visible and tiles that should be hidden.

Would you be open to doing a video call regarding this work?

[gkjohnson]

Query the tileset given a platform agnostic camera model

What exactly do you mean by this? If you mean move all camera intersection and error calculation logic in the core lib then that would effectively require a reimplementation of all the camera matrices and frustum math which already exist in their respective platforms (three.js, babylon, etc).

Retrieve a list of content that needs to be downloaded

Why do you need this? Tile content is already being downloaded in core of the library. The parsing and loading of companion data is what's required by the platform-specific implementation.

Retrieve a list of tiles that should be visible and tiles that should be hidden.

The tiles to display are already provided with the "setTileVisible" callback. If you specifically need a list of tiles to display you can maintain that using this function to add and remove tiles from an array or set.

Would you be open to doing a video call regarding this work?

Let's try to figure some of this out in the issue so it's all documented if we can first.

[FreakTheMighty]

What exactly do you mean by this? If you mean move all camera intersection and error calculation logic in the core lib then that would effectively require a reimplementation of all the camera matrices and frustum math which already exist in their respective platforms (three.js, babylon, etc).

Yeah, that's exactly what I mean :). I've taken some time to think about this and I do think that to get a 3D tile viewer javascript library that can be extended to different engines, it's going to have to ship with a math library that is likely redundant to at least one engine we're extending to. Cesium native, for example, uses glm which surely duplicates math primitives that exist in Unreal and Unity. But, this allows cesium native to provide each of these engines with the querying logic.

That's a long way of saying, maybe using three.js math primitives in the core of the library isn't such a bad thing. Its a bit redundant, but the benefit is that far more logic can be shared.

Why do you need this? Tile content is already being downloaded in core of the library. The parsing and loading of companion data is what's required by the platform-specific implementation.

Perhaps you're right that it isn't need. It does look like babylon has support for loading from an array buffer.

[gkjohnson]

I've taken some time to think about this and I do think that to get a 3D tile viewer javascript library that can be extended to different engines

Maybe we can create a thinner variant of the three.js renderer that can be extended for Babylon but generally a better implementation would just the native libraries math bindings. Otherwise you'll be importing a lot of duplicate code - three.js is not designed to be used as a stand alone math lib.

It could probably be documented better (with errors thrown in required functions) but for a basic implementation in a new engine you'd need to implement these methods:

• parseTile (parse array buffer contents to engine mesh)
• disposeTile (dispose engine mesh)
• setTileVisible (add or remove the engine mesh from what needs to be rendered)
• calculateError (calculate the error relative to relevant camera)
• tileInView (calculate whether the tile is in the relevant cameras frustum)
• optional preprocessnode (cache needed data structures for frustum culling, error calculation)
• optional setTileActive (sets whether the tile is relevant for things like raycasting or physics)

Having said that there are still quite a few things that look like they could be moved to core that don't use math constructs. Such as some callbacks or maybe other classes can be more abstracted like the "TileBoundingVolume" class or camera class that can be implemented based on engine.

Maybe good first steps are creating a basic Babylon implementation that uses three.js to see how it looks and we can move some of the obvious, non-math redundancy to core. Then we can talk about some more abstract classes to reduce redundancy further.