Skip to content

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

@loicroybon

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions