Question: Clarification on rendering ADD refinement tile children

3D Tiles
4

Here’s how I think about it…

Thanks - this is roughly the conclusion I’ve come to, as well, but I’m curious as to which other cases are handled this way. The linked function early-outs if refinement is not REPLACE or a “non-geometry” tile rather than only applying it to additive refinement tiles. Does this mean there are other conditions under which this logic is used?

This change also seems to replicate the behavior you’d see if there were an intermediate node between the “ADD” parent tile with and the geometric children that have the same bounding box as the child and the parents geometric error value:

root
refine=ADD
geometricError=500
   ├ empty child (1/256)
   | refine=ADD
   | geometricError=500
   |    └ geometric child
   |      geometricError=1
   └ ...remaining children

I’m torn between forcing out-of-spec behavior that is otherwise already possible to achieve if a tile set is structured well. At some point it’s encouraging what should be considered poorly-formed or poorly-optimized data sets relative to the spec. I’ve had users come to the project with files that have tens of thousands of children under a REPLACE node, for example, asking why it works in Cesium while it’s not loading / loading slowly in 3DTilesRendererJS project because of implementation choice made in Cesium that specifically applies to REPLACE root nodes enables it to run (see this issue).

IMO that is against the letter of the spec, but it’s a reasonable thing to do

I’m fine with adding it if this is going to be become a common optimization but it would be good to know where some of these Cesium-specific behaviors fall in terms of “canonical 3d tiles rendering behavior”, “pure optimizations with no visual sacrifice”, and “optimizations or choices that don’t align with the spec”. It would nice they were documented so users can be aware of creating a tile set that may rely on non-standard behavior. The spec should at least be changed to call this out as a reasonable “non normative” implementation if it’s going to be kept since users look at CesiumJS as “correct” behavior for 3d tiles and complain if it’s not matched.

edit

Other features from the Unreal like “an external tile set should always refine” resulting in the geometric error being ignored on external tileset also doesn’t seem to follow the spec, either (CesiumJS and 3DTilesRendererJS do roughly the same thing, it seems). At this point tile sets have been generated that rely on this behavior, though. Or at least this may be an ambiguous point in the spec? It’s something that could be clarified, I think.

1 Like