-
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
Fixed resolution scale for globe lighting and labels #8351
Conversation
Thanks for the pull request @IanLilleyT!
Reviewers, don't forget to make sure that:
|
This came up on the forum here. I can confirm this fixes the issue. In 1.63: In 1.62 and in this branch: Code:
|
@IanLilleyT add the two fixes to CHANGES.md |
mpp = czm_metersPerPixel(positionEC); | ||
positionEC.xy += (originTranslate + halfSize) * (sizeInMeters ? 1.0 : mpp); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
positionEC.xy += (originTranslate + halfSize) * (sizeInMeters ? 1.0 : mpp); | |
positionEC.xy += (originTranslate + halfSize) * (czm_branchFreeTernary(sizeInMeters, 1.0, mpp)); |
I tested a bunch of Sandcastle examples. I also checked that @IanLilleyT is going to write up an issue for testing device pixel ratio changes so problems can be caught by CI rather than manual Sandcastle checks. |
Given that this issue is much more widespread than originally though, we should do a 1.63.1 release after merging this. As part of the release I will test all Sandcastle examples on a high-dpi machine and we will have to address any additional issues that might come up (hopefully none). @lilleyse Any reason this can't be merged early tomorrow so we can go through the release process? |
7904aad
to
6d3ecda
Compare
Looks good to me. @mramato thanks for doing the patch release tomorrow. |
Congratulations on closing the issue! I found these Cesium forum links in the comments above: https://groups.google.com/forum/#!topic/cesium-dev/6yHrumlfuWU If this issue affects any of these threads, please post a comment like the following:
|
I'm still seeing difference in label quality with different DPR values. DPR 1.0 Same machine, DPR 3.0 The screenshot doesn't do it justice, but hopefully you can see the difference. Am I correct in that the goal is to have different DPR values have zero effect on rendering? You can test this yourself using the chrome responsive debugger. |
Actually, click on each image and then swap the tabs back and forth and it's pretty obvious. |
My assumption of the above is that since I'm testing on a DPR 1.0 screen and manually setting DPR to 3.0, it's actually rendering the text at a higher resolution and then downscaling, accidentally improving overall visual quality. This is probably okay, but I would like someone who knows more about the recent label changes to confirm the exact behavior so we aren't making assumptions. |
@liyangis could you create a new issue with a sandcastle that shows the problem? |
|
Fixes #8358
I rushed #8318 and missed some nuances with
czm_metersPerPixel
that affected globe lighting and labels at different resolution scales. More details about the globe lighting problem here: #8348This PR fixes those problems. I also refactored the
addScreenSpaceOffset
function insideBillboardCollectionVS.glsl
. Now all resolution scaling is handled in the shader, not the js file, for no extra cost. I tested the labels and billboards sandcastles thoroughly as well as some others, comparing against 1.60 and 1.62 releases. It seems in working order, but worth a double check.