OpenSpace / OpenSpace

This is the official GitHub repository for OpenSpace: an open source astrovisualization project. For instructions on how to build and run OpenSpace, see the Getting Started Guides on the wiki page at http://docs.openspaceproject.com.
http://openspaceproject.com
Other
764 stars 117 forks source link

Eclipse hard shadows appear to be off by a few KM #1482

Open micahnyc opened 3 years ago

micahnyc commented 3 years ago

As seen in attached images in comparison to eclipse tracker websites showing path of totality.

image

image

https://eclipse.gsfc.nasa.gov/SEgoogle/SEgoogle2001/SE2020Dec14Tgoogle.html http://xjubier.free.fr/en/site_pages/solar_eclipses/TSE_2017_GoogleMapFull.html

micahnyc commented 3 years ago

(As reported by Ken at SMSU)

hedbergj commented 3 years ago

Maybe the perfectly spherical earth?

 --local earthEllipsoid = { 6378137.0, 6378137.0, 6356752.314245 }
local earthEllipsoid = { 6378137.0, 6378137.0, 6378137.0 }
alexanderbock commented 3 years ago

Good point!

@jccosta What was the reason for the non tri-axial ellipsoid? Shouldn't it be possible to apply a non uniform scaling to the scene graph now that we have that type?

jccosta commented 3 years ago

@alexanderbock, the reason for the non-tri-axial ellipsoid is partly because of the eclipse shadow's calculation and partly because of the atmosphere's calculations. I think the problem with the eclipses' shadows alignment is one of (or all) the following (order by what I think is more probable): 1) The initial premises when calculating the eclipses. It is a geometric approximation of planets and the Sun in 2D, extended to 3D. Here, the Sun and the planets are considered perfect spheres 2) An error in the eclipses' calculation 3) Precision issues in the calculations (we are using double precision for all calculations, but we are talking about comparisons between large distances and small position on the globe) 4) GDAL tile positioning (although I think this is very improbable of happening, if the three points above are discarded, we may need to investigate this further)

hedbergj commented 3 years ago

Certainly hits St. Louis better at 18:19 on Aug 21, 2017, when the earth is oblate:

local earthEllipsoid = { 6378137.0, 6378137.0, 6356752.314245 }

(Though I'm not sure why my shadows are so chunky? - different issue I guess)

OpenSpace_000023

alexanderbock commented 3 years ago

To check: Maybe it is related to the SSB/Sun position offset that we had before

WeirdRubberDuck commented 3 years ago

So, the position of the eclipse was not improved by the SSB/Sun position change (image from master as of July 5, ffd3514b773db823b644f582a2d8fca8aee3740f). Looks like the same offset as before

image

hedbergj commented 3 years ago

with the spheroid radii in v 17

local earthEllipsoid = { 6378137.0, 6378137.0, 6356752.314245 }

eclipse-stlouis

Though, things might now be off by a minute or two (that I don't remember from before). at 18:19 GMT:

OpenSpace_000020

vs.

google-eclipse

hedbergj commented 3 years ago

Also, this was done with the oblate spheroid for the Earth asset. (and some tweaks to atmosphere so that the height at NYC latitude was correct.) It seemed pretty close to what others predicted.

eclipse-stages-2-annotated

WeirdRubberDuck commented 3 years ago

Though, things might now be off by a minute or two (that I don't remember from before).

Good catch @hedbergj. My first thought is that maybe the shadow might be offset with the same difference that the sun position had after the SSB/Sun position update... 🤔 Someone gotta look into this

hedbergj commented 3 years ago

Yeah @WeirdRubberDuck - that's probably the case. My current master is from before the atm updates @alexanderbock did very recently. Those might fix the timing for the atmosphere shadows, but then also the globebrowsing tile eclipse shadows might need to be looked at too. Changes in SSB/Sun should affect longitudinal (e/w) errors more than latitude (n/s) I bet.

WeirdRubberDuck commented 3 years ago

Yeah @WeirdRubberDuck - that's probably the case. My current master is from before the atm updates @alexanderbock did very recently. Those might fix the timing for the atmosphere shadows, but then also the globebrowsing tile eclipse shadows might need to be looked at too. Changes in SSB/Sun should affect longitudinal (e/w) errors more than latitude (n/s) I bet.

Ah, I see. For completion then, here's how it looks with the oblate spheroid Earth, including the atmosphere code updates from @alexanderbock. Hits St Luis pretty well but I'm unsure about the timing. Looks like it might be off by close to a minute, if comparing with this tool

image

alexanderbock commented 1 year ago

Maybe related to the sun position to be hardcoded to (0,0,0)? We have an issue for it, but I wasn't able to find it

WeirdRubberDuck commented 1 year ago

Maybe related to the sun position to be hardcoded to (0,0,0)? We have an issue for it, but I wasn't able to find it

You closed it as a duplicate. I just reopoened it https://github.com/OpenSpace/OpenSpace/issues/2243