-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Fix billboard and label clamping #4493
Conversation
Turns out that billboard and label clamping were fundamentally broken because the `QuadtreePrimitive` was processing the tile queue in the wrong order. It was always pulling new tiles from the back of the array rather than the front, which meant that data would get processed in the wrong order causing old tiles to take precedence over newer tiles. Addtiionally, there was a bad if block in `Label.js` which caused the initial position of the individual label billboards to not be properly set when clamping was on, instead we should always set the positions before calling `_updateClamping` (if needed). Fixes #4396 and #4062
Am i doing something wrong? #4026 doesn't seem to be fixed. The billboards look all over the place to me. var viewer = new Cesium.Viewer('cesiumContainer', {
baseLayerPicker: false,
terrainProvider: new Cesium.CesiumTerrainProvider({
url : 'https://assets.agi.com/stk-terrain/world',
requestWaterMask : true,
requestVertexNormals : true
})
});
var options = {
camera : viewer.scene.camera,
canvas : viewer.scene.canvas,
clampToGround: true
};
viewer.dataSources.add(Cesium.KmlDataSource.load('../../SampleData/kml/facilities/facilities.kml', options)); |
Works for me, are you waiting long enough, it can be slow? |
I'm not seeing the floaters anymore, but clamping perf appears a lot worse on this, because billboard and labels are dropping below the terrain before jumping back up. I tried to get a gif of it, but it ended up taking so long to represent it, the file ends up larger than 10mb. |
Yes, performance appears a lot worse because it is now more correct and doing thing in the proper order. The next step is to fix the actual performance issues but that will happen in future PRs. There's also still some clamp related bugs that need to be addressed independently, but this is definitely an important incremental improvements. |
@denverpierce what seems to be happening for me is that clamping works for a little bit, then as i zoom in and out and click around to target different billboards it seems to stop working after a little bit. @pjcozzi can you review and merge this? |
I have another change that I'm going to PR into this branch because it may be a bit controversial. |
I opened #4497, can people please try that out and let me know what you think. |
Since #4497 has been retargeted, this is ready unless there are other comments. |
Will look at this shortly. |
For #4062, the labels didn't clamp to terrain for me: |
Did you turn terrain on after you loaded the KML? If so they won't clamp because that's fixed with #4497 |
Actually, I think changing terrain is yet another unrelated clamping bug, I'm looking at that separately now. |
Works for me, but when you switch terrain, depth testing comes on, and due to #4090 KML billboards are centered, so they occlude a bit. Facilities isn't a great example, but here's how it looks when you turn on terrain with clamping in this branch: |
Thanks for testing @denverpierce. I actually think this is a bug in the |
Turns out that billboard and label clamping were fundamentally broken because the
QuadtreePrimitive
was processing the tile queue in the wrong order. It was always pulling new tiles from the back of the array rather than the front, which meant that data would get processed in the wrong order causing old tiles to take precedence over newer tiles.Additionally, there was a bad if block in
Label.js
which caused the initial position of the individual label billboards to not be properly set when clamping was on, instead we should always set the positions before calling_updateClamping
(if needed).Fixes #4396 and #4062
I already talked to @bagnell about this and he agreed it was a straight up bug. I would love to add unit tests for these, but I'm not sure what the best strategy would be.
There are still several other clamping related issues that I'm looking into; but I wanted to keep these PRs small for easier review.