Question: Clarification on rendering ADD refinement tile children

3D Tiles
7

Right, I misinterpreted the context of the REPLACE there. I should have read that (and looked at the linked issue) more closely.

There may be additional culling criteria, where the engine finds that a tile may not be completely (“mathematically”) invisible, but would add little to the visual appearance, and therefore decides not to render it. For example

  • Fog based culling
  • Screen location based prioritization/culling
  • Screen coverage based culling

I cannot say with absolute certainty which of these criteria are implemented in CesiumJS. This may be due to my lack of familiarity with these parts of the code. It may also be because these culling criteria are often not made explicit. There is no code part where you have a

for (CullingCriterion c : cullingCriteria) {
    if (c.appliesTo(tile)) discard(tile);
    else render(tile);
}

and just look at each implementation. Instead, these criteria are usually “smeared” over the traversal process, with a bunch of variables and if-checks. Specifically:

  • dynamicScreenSpaceError and associated variables and checks seem to be (similar to) what could be a FogBasedCullingCriterion
  • foveatedScreenSpaceError and associated variables and checks seem to be what could be a ScreenLocationBasedCulling

And I think that there is no explicit form of screen coverage based culling. But if I understood this correctly, then the behavior of the ADD-refinement here could be seen as a form of coverage-based culling criterion: The child tile is small and far away (thus, covering only a tiny area of the screen), so it’s not worth to really render this.
(That’s what I derived from the summaries here. I could not derive this from the /** Documentation */ of the meetsScreenSpaceErrorEarly function… …)

All that said:

I agree that there are places in the specification where the intended behavior in terms of traversal should be made clearer. This could mean that the specification becomes more restrictive (which can be difficult). But even if some aspects are left to the implementation, then this should be made explicit. This could/should include ‘Implementation Notes’, about how implementations can handle certain corner cases, or which degrees of freedom they do have, specifically (e.g. about omitting children in the ADD-case).

This also applies tol the questions about external tilesets (e.g. whether there should be some sort of “artificial” node be inserted, how to handle possible ‘gaps’, etc). And (related to that): How to handle the case of non-decreasing geometric errors. (I cannot say much more about this. Maybe someone who is more familiar with the specific implementations can chime in here).

There are several issues and threads revolving around all this (random examples are How to support placeholder tiles - empty tiles used for culling but not refinement · Issue #609 · CesiumGS/3d-tiles · GitHub or Clarification on refinement and child tiles , but many more). And it should not be necessary to reverse-engineer the CesiumJS code, which always bears the risk of people assuming that it is “correct” and “canonical” (which it may very well not be in many cases).