Engine-agnostic `region` bounding volumes for the Babylon.js and PlayCanvas renderers

Open
  • Is something wrong?
#1,785 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 4 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, three.js
Domain
computer-graphics

Research direction

Read the proposed regionToBox helper behavior and the referenced TileBoundingVolume.js implementation of setRegionData and EllipsoidRegion.getBoundingBox. Decide where a plain-number helper belongs in core and whether the Babylon.js renderer should call it from preprocessNode; the issue leaves both decisions open. Done means converting regions to 3D Tiles boxes using the supplied ellipsoid radii while preserving the tile JSON, with Babylon.js demo coverage if that renderer is included.

Written by the indexing model from the issue text.

Description

The Babylon.js and PlayCanvas renderers support only box and sphere bounding volumes, so a tile whose only volume is a region is not displayed. That rules out a lot of real data: every tile of the Helsinki city mesh, a Skyline export, uses region, as does Cesium OSM Buildings. Implicit tilesets with a region root also give every generated child a region (SUBTREELoader.js). For our Helsinki example we worked around it with a plugin that converts each region to a box in preprocessNode, but this belongs in the library.

How the three.js renderer handles it: TileBoundingVolume.setRegionData builds an EllipsoidRegion and keeps its enclosing OBB (TileBoundingVolume.js). The frustum, distance and screen space error tests all use this.obb || this.regionObb, so for culling and level of detail a region is effectively its enclosing box.

Proposal: one engine-agnostic helper in core that converts a region to a 3D Tiles box, the 12 numbers of a center and three half-axes. It would work on plain number arrays and take the ellipsoid radii, so 3DTILES_ellipsoid is respected. A renderer without region support of its own calls it in preprocessNode and handles the result like any other box. As in the three.js renderer, the region is placed in the tileset frame, not by the tile transform:

if ( 'region' in tile.boundingVolume ) {

	regionToBox( tile.boundingVolume.region, ellipsoidRadii, box );
	boundingVolume.setObbData( box, identity );

}

The math is the geodetic to Cartesian conversion and the box part of EllipsoidRegion.getBoundingBox, written once on numbers instead of in each renderer's math types. The tile JSON stays untouched, since other code reads boundingVolume.region, and the three.js renderer would not change.

Some questions before we start:

  • Is core the right home for this, and where in it?
  • Should the same PR wire it into the Babylon.js renderer? We'd test it with the Babylon.js demos.
  • Should the helper be exported for applications and plugins, or kept internal?

This covers culling and level of detail only. Rendering Earth-positioned tilesets precisely in PlayCanvas is separate engine work on large-world rendering. Until then, applications re-center the tileset themselves, as the Helsinki example does.

We'd be happy to make the PR.

Dominant language
JavaScript
Stars
2.5k
Forks
429
Avg merge
5d 22h
Merged PRs (30d)
12

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NASA-AMMOS/3DTilesRendererJS

All issues in NASA-AMMOS/3DTilesRendererJS

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.