-
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
Easy API to select a non-earth ellipsoid #4245
Comments
Unfortunately it's not as simple as we might like. You must tell the In this demo, the hover text is Cartesian3 in meters, so you can see it's the Moon's radius and not the Earth.
I vote to close this, or change it to a doc issue. |
Thanks @emackey! I updated this issue and labeled it |
I think we could do a lot better codewise here. My official recommendation for updating the ellipsoid is actually a hack'; simply set Ellipsoid.WGS84 to whatever ellipsoid values you want at the start of your app and then Cesium is guaranteed to use it everywhere. For single-ellipsoid apps, this is by far the easiest way to do it. Because of this, I think it might be worth introducing |
Of course there could be a flaw in my plan, but I'm not sure what it could be. |
I find this hack tempting, but there are potential issues. Cesium is already very reliant on the concept of a default ellipsoid, and uses WGS84 to initialize several scratch variables hidden in closures around the codebase (for example: GeographicProjection is constructed and saved as scratch in BoundingSphere and RectangleGeometryLibrary. Likewise, EllipseGeometry constructs one that gets saved in CircleGeometry, even though the latter appears to be constructing a unit sphere and yet contains a hidden default reference to WGS84. You can find these and more such examples by modifying WGS84 to be Resetting the default ellipsoid in user code, even if done before constructing a viewer, cannot happen in time to reset all of these pre-constructed scratch variables. Specifying the ellipsoid manually, in each and every place it is needed, is currently the only way to have some hope that the factory default doesn't creep in anywhere... but I don't know of any way to enforce that with tests such that newly-added default ellipsoid references get detected somehow. Perhaps we assign Ellipsoid.Default to be the unit sphere during startup, and then reset it to WGS84 just before handing off to user code? That might force these issues to the surface, since any code holding onto a unit sphere would presumably be obviously wrong for the Earth. I still have long-term hope of visualizing interplanetary missions in Cesium with multiple central bodies in one window. We'll need to have a good way to avoid reliance on defaults for that. |
CC #4069 |
Looks like the ground atmosphere has to be turned off for this to work now: |
news about multiple globes/ellipsoids for planets representation? |
Users on the forum want to use non-earth ellipsoids but it is unclear how they have to set it.
The text was updated successfully, but these errors were encountered: