using UE5.7:
created with wizard google maps tile set.
set cesium geo reference to true north (geocentric)
the sun rises in the south and sets in the north.
tried to find a way to fixed it. no luck.
Hi @Tamir_Offek, welcome to the forum!
Could you outline the exact steps you took to recreate this? I tried:
- Add GP3DT and set georeference latitude to 90, longitude 0. This places the origin on true north
- I could change the month/day and timezones and it appears the sun is in the correct position.
Are these the steps you took?
Thanks for the follow up
Hey @Tamir_Offek ,
This seems to be a known issue based on this github issue. I would note that we don’t recommend using true origin mode (line 18 here) for most use cases.
What is your use case, does it require true origin? It would be useful to know so we can better advocate for the fix internally.
I will link to this topic on github to express interest in the issue.
Thanks for posting on the forum!
I would recommend working around this issue by creating a second georeference and setting the CesiumSunSky to use that georeference instead. You can then place that georeference wherever you want to treat as the center (in terms of correct sun placement) and still use the original georeference in true origin mode. Though I would recommend not using a global tileset in true origin mode, it’s meant for situations where the tileset itself isn’t properly georeferenced.
for several reasons I need all the elements in the level to be aligned to geocentric mode (true north).
does cesium aware of this bug?
I need it in order to to get two far points on the globe to use the same axis system and this system should still be correct for both points. if you are using cartographic mode (with base LLA) points that are far from the base LLA use incorrect local axis system that gets increasingly erroneous as the point distance from base LLA is increasing.
Have you tried azrogers solution? I think that’s a great place to start, let us know if you run into any issues with that, thanks!
hi darcyvdd.
this solution is not applicable for me.
cesium is one part of an entire complex level with self developed plugins and complex scenario. accuracy is crucial and no part of the scenario can use base LLA method due to its inherent inaccuracy over long distances.
I guess cesium is aware of this bug.
are there any plans to fix it?
thanks.
@Tamir_Offek What inaccuracy are you running into with long distances when using the method I suggested (using two georeferences)? This should not affect any other calculations you do, it should only affect the positioning of the sun - and I don’t think there are accuracy issues with LLA regardless.
hi azrogers
I need high accuracy and i have multiple plugins that work with cesium.
it is not applicable for this scenario to use this workaround.
are there any plans to fix this bug in cesium sun sky?
is there any way to force the correct sun position manually or from cpp by changing some of sun sky values?
also, the time of day of sun sky having a bug. i.e. hour 1400 is setting the sun in a low (sunrise in the north) position. is there a workaround for that?
Hi @Tamir_Offek,
Pardon the intrusion, but I think there’s some miscommunication, and I want to make sure align on what’s going on as we try to help.
First, the CesiumGeoreference only supports two modes: Longitude/Latitude/Height and True Origin. I assume that some previous references to “True North” are actually meant to be True Origin, but please correct us if you meant differently.
There are calculations in CesiumSunSky to position it based on the Longitude, Latitude, Height of the CesiumGeoreference (example). This is so that the sky appears correct relative to the chosen LLH on the CesiumGeoreference. Indeed, this does not adapt to True Origin mode, and that bug is recorded on the GitHub issue @darcyvdd linked above.
It is unfortunate to hear that you’re experiencing accuracy problems, especially when Unreal Engine already uses double-precision coordinates and our systems take full advantage of that. But ultimately, we can’t provide more insights without knowing more details about your setup. We fully understand that there are likely are privacy / proprietary concerns preventing you from sharing more details; this is just the reality of the situation.
We do not have a timeline for fixing the aforementioned bug, but please feel free to download the source code and modify it as you need. We would also accept a community contribution for this if you (or other community members) are able to find the solution.
Let us know if we can help in any other way!
hi janine.
I did meant True Origin 
My accuracy issues stem from the inherent limitation of using base LLA. At any given point on Earth, the local up/forward/right vectors are only correct for that specific location. When other points in the world that are far enough from the base LLA, they still use those same vectors even though, at their actual geographic position, the vectors would be slightly rotated (for example, the “up” vector is no longer truly pointing up). Because we place actors in those distant locations, their orientation becomes incorrect. Moving the base LLA during running (for higher local accuracy) of the scenario only makes the problem worse.
We also rely on Cesium’s georeferencing system for our calculations, and we need all calculations in the scene to remain consistent and uniform.
When we use true origin the problem is solved (except for the sun sky)
Thanks for sharing your plans to address this issue.