Break Sun Position Data - Weird Float

Hey All,

I seem to be experiencing some calculation errors with breaking down sun position data. I have my day night cycle using the sun position calculator. Everything is working great except occasionally while the sun is playing through its timeline it seems to “bounce”. Due to this, I outputted the elevation breakdown into the console. For some reason the elevation will go from 201.077713 to 200.844666, or for instance 203.208511 to 202.975906. It should continue to increase, not roll back. I will post screenshots of console output and calculation blueprints. Why is it doing this and how would I go about fixing this bug?

I was having the exact same issue, even with a blank project. I was surprised to not see more people complaining about this issue. In short, if you make a Day/Night System and hook it up to the Sun Position Calculator Plugin, the sun and shadows jitter every now and then.

I found that the problem was caused by the GetHMSFromSolarTime Function, particularly the Seconds section.

There was some strange math in the default template, I simplified it a bunch (I also made the function take the Solar Time Variable directly, and turned it into a Pure function) and it’s now working flawlessly.

1 Like

The sun position calculator “strange math” is acrually science.

The system supposedly (with very bad accuracy) positions the sun based on a julian date, so in theory you can set your lon/lat and get a screenshot of where the sun would have been at X point in time (past or future).

Considering what it is - the pss poor accuracy is just fine. The margin of error probably breaks down to the sun being a few deegrees off on that hour, which great scheme of things is not bad.

The system itself isnt really designed to do a day/night cycle - because operating these calcs at runtime is outright insane.

The error experienced above was probably some floating point issue with one of the calculations - even back when the engine we all set to float, some calcs would break down. Just the nature of computer math.
The issue gets compounded when you try to do things you should not (like run these complex calculations at runtime to get the directional light to move).

Instead,
Placing your sun/game project on the equator is always going to be the cheapest solution.
But for the 2c it costs you, go and learn what Right Ascention and Declination mean.
Learn how to calculate a position based on Lon/Lat.
Run the math once to get the approximate angle you need your sun to run at.

From then on, I suggest just turning it around to where you effectively only change one rotational value over time like you would for an equator setup. Leave the other angle be even if its inaccurate so long as it looks close to what you want.

Then apin the sun - but for a day cycle you need to habdle a lot more than just position and light intensity. The landscape or meshes will also need a light blocking box underneath to prevent Unreal from… well, being unreal.
It’s all smoke and mirrors and quite honestly, a flat earther’s wet dream by design. So you really jeed to learn the basics of whe things really work like, and have enough brain power to convert them into flat earth nonsense to get unreal to look good when using the built in systems (and light sources).

BTW - the latest engine kismet Modulus calculations give worse errors than prior versions because of their change to using Double (i think bad functions are at play, so they’ll eventually get patched) - but in 5.x you cannot rely on blueprint math do something that needs a modicum amount of precision like the day cycle.
Not sure where that leaves the BP only people.

Everyone else should really just implement a julian date calc function in c++, run it once or twice per day cycle to re-align stuff provided the CPU ms cost of the function is neglectible when the rest of your game is working.
Or just leave it there, use it on level start only…

Whats the idea here? You skimmed my post and misfired?

No, the function for calculating the suns position on the sky is written in c++ and is neither touched nor mentioned.

It’s really simply an issue with the function inside the template that converts the 24h float value to three (HMS) integers which is poorly set up. This solution is valid for anyone looking to use the plugin, and is expecting to see smooth sun angle movements.

When it comes to the performance of it, or the general performance of Modulus calculations in Blueprints - let’s take that elsewhere shall we?

2 Likes

No.
It’s 100% related since you are using mod to figure out your time/hours. And you are also likely on some 5.x version of the engine.

Don’t discount it simply because your limited testing worked. There are definitely bound to be instances where it won’t. Until they patch it and stabilize things at least (like 2027 ish I predict).

The rest is more of an explanation as to why you do not see people complaining about it. It’s not something you want to use at runtime. And it’s also not something that is widely used in game setups just in general, so very limited amount of users compared to other things.