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

Contrast / saturation adjustments causes render issues on Linux since Cesium 1.52 #7382

Closed
ulrichson opened this issue Dec 4, 2018 · 5 comments

Comments

@ulrichson
Copy link

Since Cesium 1.52 tweaking the contrast adjustment (any value != 1) will cause rendering issues on Linux:

cesium-1 52-linux

Parts appear black, similar result when saturation is adjusted to a higher value. The previous Cesium version with adjusted contrast / saturation worked fine on my machine.

Sandcastle example: https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/index.html?src=Imagery%20Adjustment.html

Browser: Chrome 70 / Firefox 63

Operating System: Ubuntu 18.04.1 LTS

Graphics: GeForce GTX 1060 3GB with NVIDIA driver 390.77

@mramato
Copy link
Contributor

mramato commented Dec 4, 2018

Thanks for writing up an issue @ulrichson.

This has actually been a problem on the Windows side for a long time. I'm under the impression that it was an Nvidia driver bug. On my Linux machine (Ubuntu 18.04.1 LTS) the issue only appears when running under my GTX 1050 and does not happen when using the Intel GPU. It's definitely possible that it's an issue in an nvidia-only share path in our code. (Happens on my Windows 650ti every time).

Maybe someone can finally track it down.

@ulrichson
Copy link
Author

@mramato thanks for the update!

I found out that the issue appears when Scene.highDynamicRange = true (as it was introduced in 1.52). When I disable it the adjustments work as in < 1.52.

@mramato
Copy link
Contributor

mramato commented Dec 18, 2018

Thanks for the extra info @ulrichson.

@bagnell any idea where the problem might be?

@mramato
Copy link
Contributor

mramato commented Dec 19, 2018

@ulrichson thanks again for reporting this, it will ship with the next release (on Jan 2nd).

@thw0rted
Copy link
Contributor

thw0rted commented Apr 3, 2019

Could this fix have caused #7707 ?

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

No branches or pull requests

3 participants