Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3D Tiles - refine to visible children in replacement refinement #4287

Merged
merged 15 commits into from Sep 7, 2016

Conversation

lilleyse
Copy link
Contributor

@lilleyse lilleyse commented Sep 6, 2016

For #3241

Performance: optimize replacement refinement - instead of requesting all children when a tile needs to refine, request only the visible ones, and then allow refining a tile if all the required visible tiles are loaded (instead of all - including invisible - tiles). When the camera moves, and children that are not yet loaded are needed, either render the parent or render the available children and the parent with clipping.

When not all visible children are loaded, I go with a third approach - render the parent and available children together, which is slightly noticeable in some cases but doesn't hurt visual quality since the other visible children usually load in soon after.

Since the visibility check must now happen in the replacement refinement path, I save the result and don't recheck the visibility once the tile is popped from the stack. I modified the additive refinement path to do the same, store the planeMask now and use later.

I also ended up reverting #4280 because otherwise the bounding volume check will happen twice, first in the selectTiles loop, and again in selectTile. This only applies to tiles without content bounding volumes, which is many replacement tilesets. As long as contentsVisibility is called after visibility is already checked, this should be ok.

Some numbers:

Now that we don't need to request all children, and instead just the visible ones, there are some memory improvements. In real world tilesets I've noticed between 14% to 50% savings in the number of loaded tiles. These numbers below are for a generic replacement refinement tileset:

Before

View Loaded Rendered Total tiles in tileset
Horizon 233 152 341
Straight Down 135 53 341

After

View Loaded Rendered Total tiles in tileset
Horizon 210 152 341
Straight Down 86 53 341

@pjcozzi
Copy link
Contributor

pjcozzi commented Sep 6, 2016

I go with a third approach - render the parent and available children together, which is slightly noticeable in some cases but doesn't hurt visual quality since the other visible children usually load in soon after.

Can you please test this with several different datasets to get a feel for how bad it can be so we know how to prioritize clipping parents with their loaded children?

@pjcozzi
Copy link
Contributor

pjcozzi commented Sep 6, 2016

As long as contentsVisibility is called after visibility is already checked, this should be ok.

Add a comment for this inside contentsVisibility and the reference doc (which is likely to be skipped when stepping debugging).

@pjcozzi
Copy link
Contributor

pjcozzi commented Sep 6, 2016

86% savings

More like 14%, right?

Also, what is the Total column? It is always 341.

@@ -294,6 +294,13 @@ define([
this.replaced = false;

/**
* The stored plane mask from the visibility check during tree traversal.
*
* @type {Boolean}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this CullingVolume?

@@ -536,6 +514,42 @@ defineSuite([
});
});

it('replacement refinement - refines to visible ready children', function() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With all the tileset traversal changes, are you sure this is the only new test we need? Are all cases covered?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though the test seems simple it does cover all the new traversal cases.

@lilleyse
Copy link
Contributor Author

lilleyse commented Sep 7, 2016

More like 14%, right?

Hah yeah, I updated the comment.

Also, what is the Total column? It is always 341.

Changed the name from "Total" to "Total tiles in tileset". It's always 341.

@lilleyse
Copy link
Contributor Author

lilleyse commented Sep 7, 2016

Can you please test this with several different datasets to get a feel for how bad it can be so we know how to prioritize clipping parents with their loaded children?

Some datasets are more noticeable than others, I think we will need to explore parent clipping to make this better.

@lilleyse
Copy link
Contributor Author

lilleyse commented Sep 7, 2016

Updated. I still need to add a flag to enable/disable this optimization.

@pjcozzi
Copy link
Contributor

pjcozzi commented Sep 7, 2016

I still need to add a flag to enable/disable this optimization.

Will review and merge when this is ready.

@lilleyse
Copy link
Contributor Author

lilleyse commented Sep 7, 2016

Updated.

@@ -536,6 +514,42 @@ defineSuite([
});
});

it('replacement refinement - refines to visible ready children', function() {
viewRootOnly();
return Cesium3DTilesTester.loadTileset(scene, tilesetUrl).then(function(tileset) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Run this test twice, once with refineToVisible set to true and once with it set to false?

@pjcozzi
Copy link
Contributor

pjcozzi commented Sep 7, 2016

Do you get these test failures with http://cesium-dev.s3-website-us-east-1.amazonaws.com/cesium/3d-tiles-refine-visible/Specs/SpecRunner.html?spec=Scene%2FCesium3DTileset

Scene/Cesium3DTileset does not select tiles when outside of view frustum
Failed: promise rejected: DeveloperError: parentPlaneMask is required.
DeveloperError@http://cesium-dev.s3-website-us-east-1.amazonaws.com/cesium/3d-tiles-refine-visible/Source/Core/DeveloperError.js:44:19

Scene/Cesium3DTileset replacement refinement - refines to visible ready children
Expected 5 to equal 2.
stack@http://cesium-dev.s3-website-us-east-1.amazonaws.com/cesium/3d-tiles-refine-visible/ThirdParty/jasmine-2.2.0/jasmine.js:1475:17

Scene/Cesium3DTileset tile visible event is raised
Failed: promise rejected: DeveloperError: parentPlaneMask is required.
DeveloperError@http://cesium-dev.s3-website-us-east-1.amazonaws.com/cesium/3d-tiles-refine-visible/Source/Core/DeveloperError.js:44:19

Scene/Cesium3DTileset tileUnload event is raised
Failed: promise rejected: DeveloperError: parentPlaneMask is required.
DeveloperError@http://cesium-dev.s3-website-us-east-1.amazonaws.com/cesium/3d-tiles-refine-visible/Source/Core/DeveloperError.js:44:19

@pjcozzi
Copy link
Contributor

pjcozzi commented Sep 7, 2016

Just those comments.

@lilleyse
Copy link
Contributor Author

lilleyse commented Sep 7, 2016

Those test failures are fixed now, and a new test is added.

@pjcozzi
Copy link
Contributor

pjcozzi commented Sep 7, 2016

Thanks @lilleyse! Huge improvement here.

@JPhPons
Copy link

JPhPons commented Mar 1, 2017

Hi,
I observe a strange phenomenon on our 3D tiles of Marseille with a recent version of the 3d-tiles branch. Sometimes, tiles with very low resolution are displayed together with high resolution tiles. See the attached screenshot:
c3dt overlapping ancestor
It should not be related to this PR, as I do not activate the refineToVisible option... Could it be an unwanted side-effect of this change, or another optimization in the replacement refinement?
Thank you in advance for your help,
Jean-Philippe

@lilleyse
Copy link
Contributor Author

lilleyse commented Mar 1, 2017

@austinEng can you verify if this is related to the child-union optimization?

@lilleyse
Copy link
Contributor Author

lilleyse commented Mar 1, 2017

@JPhPons if you pull the latest 3d-tiles branch and construct the tileset with cullWithChildrenBounds as false, do you see the same artifacts?

@JPhPons
Copy link

JPhPons commented Mar 2, 2017 via email

@lilleyse
Copy link
Contributor Author

lilleyse commented Mar 2, 2017

Ok thanks for checking. Did you start to experience this problem recently? Is it occurring with other tilesets? It reminds me of issues we used to see with replacement refinement with empty tiles (like #3517).

Feel free to send me the tileset for testing.

@pjcozzi
Copy link
Contributor

pjcozzi commented Mar 6, 2017

@JPhPons @lilleyse any update here?

@JPhPons
Copy link

JPhPons commented Mar 31, 2017 via email

@lilleyse
Copy link
Contributor Author

The attachment doesn't seem to go through with github replies, but you can send it to me directly or otherwise open a PR.

As a side note, the 3d-tiles traversal is about to get a large overhaul and likely fixes the issues here - #5128

@lilleyse
Copy link
Contributor Author

Thanks for sending it over. The diff seems fine as an interim fix. Would you like me to open a PR?

@JPhPons
Copy link

JPhPons commented Mar 31, 2017 via email

@lilleyse
Copy link
Contributor Author

Opened #5171

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants