3D Tiles - Refinement based on proximity

[lilleyse]

For CesiumGS/3d-tiles#101

Not ready until #4130 is ready.

If viewerRequestVolume has multiple sub-properties, the viewer needs to be in the union of them?

I'm not handling this right now. We don't handle it for our other bounding volumes either so maybe we should wait to do them all at the same time.

For replacement refine, I think it is fine to refine the parent and only render the children that base the new volume test (even if it isn't all of them), but we should refine the parent until at least one child is ready to render and visible.

For the sake of making the implementation super easy, I left out this point for now.

To do:

• Fix debug volume not drawing.
• Add debug volume button to Sandcastle example.
• Example dataset for Sandcastle example.
• Unit tests
• Replacement refinement, 3D Tiles - Refinement based on proximity #4138 (comment)

In action, and working with the transform property:

[pjcozzi]

If viewerRequestVolume has multiple sub-properties, the viewer needs to be in the union of them?

I'm not handling this right now. We don't handle it for our other bounding volumes either so maybe we should wait to do them all at the same time.

Should be trivial, just check each with ||, but....maybe we should just change the spec to allow only one sub-property (for this and all BVs. We could loosen it later if there is a good use case.

What do you think?

We don't handle it for other bounding volumes because for them the spec says that it is OK to use any bounding volume.

[pjcozzi]

Hopefully this was obvious, but this

For replacement refine, I think it is fine to refine the parent and only render the children that base the new volume test (even if it isn't all of them), but we should refine the parent until at least one child is ready to render and visible.

should have been:

For replacement refine, I think it is fine to refine the parent and only render the children that pass the new volume test (even if it isn't all of them), but we shouldn't refine the parent until at least one child is ready to render and visible.

OK to wait on this.

[pjcozzi]

Added above:

• Add debug volume button to Sandcastle example.
• Unit tests

[pjcozzi]

Also added:

• Example dataset for Sandcastle example.

[pjcozzi]

Looks good!

[pjcozzi]

If viewerRequestVolume has multiple sub-properties, the viewer needs to be in the union of them?

I'm not handling this right now. We don't handle it for our other bounding volumes either so maybe we should wait to do them all at the same time.

Should be trivial, just check each with ||, but....maybe we should just change the spec to allow only one sub-property (for this and all BVs. We could loosen it later if there is a good use case.

I changed the spec so that only on property will be in any boundingVolume object.

[pjcozzi]

For replacement refine, I think it is fine to refine the parent and only render the children that pass the new volume test (even if it isn't all of them), but we should refine the parent until at least one child is ready to render and visible.

For the sake of making the implementation super easy, I left out this point for now.

Looking at this again, the request volume test only applies to the parent so if it passes, replacement refinement continues as usual with no special cases needed. Implicit in this is some or all of the children may have request volume tests that fail. See how these feels in practice and we'll update the spec accordingly.

[pjcozzi]

@lilleyse should this be retargeted to 3d-tiles so we can delete the 3d-tiles-transform branch?

[lilleyse]

This is now ready.

I added 1513fbb to address #4138 (comment), but I'm not sure if the overhead is worth it.

[lilleyse]

@pjcozzi Ready when you have a chance.

[pjcozzi]

I added 1513fbb to address #4138 (comment), but I'm not sure if the overhead is worth it.

Looks OK to me. We'll reconsidered later if need be.

[pjcozzi]

Part of #3241

[pjcozzi]

Looks good!