debugShowBoundingVolume: Region volumes not drawn (sometimes)?

[bertt]

Hi,

When using debugShowBoundingVolume I observe that boundingVolume regions are sometimes not drawn.

For example:

1] Boundingvolumes drawn

https://bertt.github.io/cesium_3dtiles_samples/samples/boundingvolumes/index_drawn.html

Region: [
-1.3197219872492525, 0.6823609056767111, -1.3165943572296785, 0.6843854876090245,
-0.0,
76.58
]

2] Boundingvolumes not drawn

https://bertt.github.io/cesium_3dtiles_samples/samples/boundingvolumes/index_not_drawn.html

Region: [
0.08687725417652173, 0.9093531922033375, 0.09051102967917393, 0.9087615255869115,
-0.0,
76.58
]

The only difference is the region: Delaware (drawn) - Utrecht (not drawn)

Q: How can we draw the boundingVolume regions with debugShowBoundingVolume in Utrecht too?

[Marco13]

This is almost certainly caused by the bounding region being invalid: Its south value is greater than its north value.

This is not (yet) mentioned in the specification, but probably will be added soon: A fairly recent issue has been opened for this and other clarifications: Clarifications and additions for the specification · Issue #711 · CesiumGS/3d-tiles · GitHub

Here is a sandcastle that shows the rectangle with north and south swapped. Your original coordinates are commented out - using these will cause a

DeveloperError: options.rectangle.north must be greater than or equal to options.rectangle.south

But with north not being smaller than south, it should work:

Cesium Sandcastle

[bertt]

Ah yes thanks, that was it!

[bertt]

When using the ‘correct’ order of north and south I notice tiles disappearing when zooming in (see https://bertt.github.io/cesium_3dtiles_samples/samples/boundingvolumes/index_not_drawn_fixed.html)

This does not happen with the ‘incorrect’ order of north and south (https://bertt.github.io/cesium_3dtiles_samples/samples/utrecht3d/)

[Marco13]

I started having a look at this, based on the sample data.

^{(With one small aside: I moved the JSON into the utrecht3d directory, to avoid using the absolute paths for content URIs - while this is valid, it will reduce portability, but I assume that this was only done here for tests/debugging).}

Everything that I say here should be taken with a grain of salt (I’m not so deeply involved in the inner workings of CesiumJS). But I made a few observations:

I added an obscure hack to show the bounding regions of the tiles, as rectangles, with some “label” that shows the implicit tile coordinates (as level-x-y).And I extracted the GLBs from the B3DMs, and had a look at these as well. The following is a screenshot showing the tiles 3-7-4 and 3-7-3 on the left. On the right, I opened the corresponding GLBs in another viewer, 3-7-4 at the top, and 3-7-3 at the bottom:

Obviously, they appear to be “flipped”. Not in the sense of a “scale along the (visual) Y-axis”. Each tile has the right orientation. But they are displayed “in the wrong order”.

So far, so strange. But … this “wrong order” is apparently also used for culling, as it can be seen here:

When dragging the mouse, so that the bottom tiles leave the viewport, then the top tiles start to disappear. When dragging so that the top tiles leave the viewport, then the bottom tiles start to disappear.

---

Until now, this may not be sooo helpful. It is only an an observation of symptoms. It is not even clear (for me) whether it is some “error” in the data, or a bug in CesiumJS. I considered to create a manual, minimal example (just 4 unit cubes in a quadratic region), just to see whether it can be reproduced with a simpler example as well, but that might take some time. Maybe someone already has an idea where to start looking, based on that description. (I started digging in the code, but no avail…).

[bertt]

ok thanks for looking into it.

A smaller example of the issue (only drawing schools with 2 levels):

1] Working

• North/South ‘wrong’ order

• Debug BoundingVolumes not drawn

• Can zoom in to school details

https://bertt.github.io/cesium_3dtiles_samples/samples/boundingvolumes/schools/index_working.html

2] Bad

• North/South ‘correct’ order

• Debug BoundingVolumes are drawn

• Can NOT zoom in to school details

https://bertt.github.io/cesium_3dtiles_samples/samples/boundingvolumes/schools/index_bad.html

The only difference between the two samples is the order of north/south in tileset.json. With only 1 level (0) I can not reproduce this behaviour.

[bertt]

On closer inspection it looks like the tiles are not correctly placed

tile 1,0,0 is placed at 1,0,1 and vice versa

tile 1,1,0 is placed at 1,1,1 and vice versa

If true this would explain the disappear when zooming in. I’ll check more tomorrow

[Marco13]

The “schools” example also shows the behavior of tiles disappearing when the “opposite” tiles leave the viewport. When you say that “the tiles are not correctly placed”, does it mean that you suspect an error in the input data? I wasn’t sure whether this was caused by the data, or by some internal computation (of bounding boxes, or maybe some transform matrix) of CesiumJS.

(In doubt, I’d also have a closer look, but might need to allocate some time for that…)

[bertt]

yeah it was something with the input data (sort of inverted y-axis going on after going from epsg 4978 to 4326), I fixed it and can now see the debug boundingVolumes and zoomin to detail see https://bertt.github.io/cesium_3dtiles_samples/samples/boundingvolumes/schools/fixed/