Feature Request: Add a Highly-Decimated Root Level (LOD 0) + Consider Alternative Spatial Structures

[loicroybon]

Hello,
While using obj2tiles to generate 3D Tiles datasets for viewers such as [NASA 3d-tiles-renderer-js](https://github.com/NASA-AMMOS/3DTilesRendererJS), we have encountered recurring issues when loading certain scenes.

Problem Statement

For some models, especially those that:

• Have a very large spatial extent (landscape-scale datasets);
• Or have a very elongated shape (corridors, roads, linear networks);

the generated tileset does not include content at the root level (root.content is null and refine: "ADD").
This leads to the following behavior:

• Nothing is visible initially — the viewer renders an empty scene until children tiles are selected.
• Children tiles are only refined once their Screen Space Error (SSE) exceeds the threshold, which might require zooming very close before any geometry becomes visible.
• More compact or cube-shaped scenes are less affected by this behavior and load more intuitively.

This has been noted by other users as well — see the forum discussion [About the choice of Obj2Tiles’ spatial data structure](https://community.opendronemap.org/t/about-the-choice-of-obj2tiles-spatial-data-structure/18612), which raises concerns about the subdivision strategy and its effect on the number of tiles and performance.

---

Analysis

This behavior is compliant with the 3D Tiles specification: refinement is driven by SSE, and without root content, no “context LOD” is rendered until children are considered necessary.
For very large models with small geometricError values, this results in a “blind navigation” phase before any tile becomes visible, creating confusion for end-users.

The above-mentioned discussion also points out that the current subdivision strategy leads to a very high number of tiles for large models (>1000), which negatively impacts loading time and runtime performance. Alternative spatial structures (such as kd-trees or octrees, similar to [Nexus](https://vcg.isti.cnr.it/nexus/)) could reduce the number of top-level tiles and make the dataset much more efficient to stream.

---

Proposed Change

1. Add a Very Simplified Root LOD

   • Generate a highly decimated mesh (few hundred/thousand faces max) attached to root.content.
   • Keep refine: "ADD" so that higher-resolution children overlay progressively.
   • Provide a CLI flag to control the simplification ratio (e.g., --root-simplification 0.005 for 0.5% of original faces).

2. Consider a More Adaptive Spatial Structure (Octree / kd-tree)

   • As suggested in the referenced discussion, switching to a kd-tree or octree subdivision could:

     • Minimize the number of tiles at the lowest levels,
     • Concentrate tile density where it is most needed (high-detail regions),
     • Improve loading time and runtime performance for large models.

[dknezevic]

Regarding number 1:
it seems to me that all you need to do in order to solve the issue you have is adjust the tileset.json, more specifically, the geometricError property for the root tile. Additionally, your viewer settings also need to be updated to display the tiles when you actually need them. Doesn't look like an issue with the obj2tiles library to me. Could be wrong though, and dont actually understand the problem you have. I have very large, long etc models that render very well, but the thing is, it doesn't come out of the box.

I could help with the change number 2:
I have implemented the octree variant in my local fork. i could maybe create a pull request with this feature. It just needs some code cleanup so that i can merge it to main branch as im already far away from the original code :)