-
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
SDF Text Labels! #7730
SDF Text Labels! #7730
Conversation
visualize the contents of the BillboardCollection's TextureAtlas.
Thanks for the pull request @jasonbeverage!
Reviewers, don't forget to make sure that:
|
@jasonbeverage I haven't looked at the code yet but these were some of the things I noticed while going through all the Sandcastle examples:
Some of the ones I noticed it on was Callback Property, CZML Reference Properties (used in the gifs), and KML.
|
Would we want to use SDF in |
|
Hi @lilleyse, I pushed some changes that should fix the crash and the odd label positioning you were seeing. When I added the CSS font based scaling I ended up breaking the positioning. I also pushed a dynamic SDF scale factor that seems to look pretty good as well. Give it a look and see what you think. |
instead of the billboard dimensions. Using the billboard dimensions assumes that the text is very tightly centered in the glyph itself which isn't always the case with the SDF generated text. We'll look to tighten up the glyph size so it isn't unnecessarily big, but this this change should work in all cases so matter how much padding we have around the glyphs.
The outline color alpha doesn't seem to be blending properly: working sandcastle on cesiumjs.org |
@jasonbeverage I went through the code and thought it looked pretty good. I pushed a commit with style tweaks 56ca95a and left a few comments. |
… that just does a single sample with a fixed smoothing.
@jasonbeverage the updates look good, thanks! |
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.
Thanks again, @jasonbeverage. I only briefly reviewed and left hopefully a few useful comments and perhaps a few truly minor ones.
Some thoughts:
- Would you like to write a short guest blog post about this? Maybe a tad about the implementation, but more about why this feature matters, the visual quality improvement, etc.
- Did you do any performance tests compared to the traditional raster approach? Like add 10K static labels so that the fillrate is ultra high and see the difference. It's OK for it to be slower under load, but it would be good if we had a handle on it.
- Also for performance, do you have any concerns on dynamic use cases, e.g., constantly updating a label like a number would be the most important one, but I imagine there are some slow paths such as changing the font, maybe size, etc. Totally OK, would just like to know what they are.
Thanks! 🚀
@pjcozzi sorry I missed these reviews coming through for some reason, I'll try to address them as soon as I can. To respond to your questions:
|
|
…e z and w components were 0
Storing imageIndex as a local variable to avoid redundant compuations
Hey @pjcozzi I addressed most of your reviews with either a code change or a comment. I'm going to take a look at a FPS test next. |
I did a little sandcastle test to display a big number of labels
At 10K labels there is no difference between the master and the SDF branch on my machine, they both run at 60fps with the globe totally covered in labels. At 100K labels the master runs at 10fps and my SDF branch runs at 7fps, so there is a difference in performance at some level but 100K labels is such an extreme case I don't think its going to be noticeable to anyone doing a sensible use case in Cesium. |
@jasonbeverage great news on performance; does not sound like a concern at all for the cases you tested. For test coverage, the best thing to do would be to just run coverage and double check that the new code paths are covered well. Have you done this? See https://github.com/AnalyticalGraphicsInc/cesium/tree/master/Documentation/Contributors/TestingGuide#run-all-tests-against-combined-file-run-all-tests-against-combined-file-with-debug-code-removed Otherwise, I'll leave it to @lilleyse for the final merge and release as time allows for him. |
Added Label.totalScale property to CHANGES.md
Rather than keeping a fontInfoCache in LabelCollection the font properties are stored on the Label itself and the parseFont function is called when the font string changes.
I did one last smokescreen through the Sandcastle examples and they look fine. Thanks @jasonbeverage! I'll try to get to #7875 this month so SDF can look even better, |
Awesome, thanks @lilleyse! |
Hi everyone!
This PR adds Signed Distance Field (SDF) text rendering to Cesium. Signed Distance Fields are a rendering technique made popular by Valve for rendering crisp, scalable text (and other images) without using a ton of texture memory. Regular bitmap fonts tend to start to look bad when they are rotated or when they are scaled up or down, but Signed Distance Fields solve this problem by storing the "distance" from the edge of a glyph in the texture instead and using a special fragment shader that can render crisp antialiased edges.
This isn't totally done but I wanted to get it out there to get some feedback.
Here is an example of what the new fonts look like.
Here is a summary of major changes to Cesium.
What is left to do?
Looking forward to your feedback!