openmw.org

Hi,

I work on moon correct behaviour based on fallback settings. Basic idea is calculation of orbit orientation, amplitude and angular frequency for the moon. Position calculation then consists of amplitude rotation using quaternion depending on gameHour.

There is need for further research on dailyIncrement. Moon goes around within (24 - dailyIncrement) hours when its speed is 1. Waning and waxing is disabled if dailyIncrement is 0. It's harder to test since 'set day/month/year to X' doesn't cause immediate recalculation of the position.

I think that amplitude is influenced by texture size of the moon. To test that, texture size must be modified inside bsa archive. Bsa extraction isn't problem but I don't know howto change texture size right now. But this can wait.

Regarding source code:
Sun and Moon calculations are done from two places - WeatherManager/update and SkyManager/update. Why is that?
Further there are two magical constants inside BillboardObject. 450 used to scale size and 1000 to scale position - from where this came from?

Don't know about these constants. Reverse engineering by guessing maybe?

WeatherManager is part of the mwworld subsystem. SkyManager is part of the mwrender subsystem (going for more consistent naming would probably have been a good idea). Think of it like a model/view design (mwworld being the model and mwrender the view).

450 is just arbitrary value used to get proper size. I've imported fallback moons sizes, grabbed ruler, and compared moon sizes in vanillia and openmw, and I've been changing this value until it was equal.

I intend to create SolarSystem class to abstract Sun/moons updates from calendar, because hour of first appearance of moons depends on TimeStamp and fade level with waning/waxing also depends on Sun position. This allows simplified calculations based on time differences and it also gives a hand for further improvement of sky objects.

SolarSystem will simply manage Tamriel satelites according to flow of time.

Then if you change calendar (which is inconsistent across TES series) it won't affect moons - you simply recalculate initial SolarSystem setting when game is loaded. As a side effect you could run time backwards.

IIrC, bloodmoon expansion uses some script interaction that changes moon posistion or size during the werewolf quest.

ST

In Bloodmoon the small moon (Secunda) is colored red during Hircine's Hunt quest, hence the name of the expansion. This is done with the TurnMoonRed script instruction and can be changed back with TurnMoonWhite.

Example:
1) speed = 1, daily increment = 0
appearance at 0:00, time to travel 90 degrees: 6 hours
next appearance at 0:00
2) speed = 0.5, daily increment = 0
appearance at 0:00, time to travel 90 degrees: 11.5 hours
next appearance at 0:00
3) speed = 0.75, daily increment = 0
appearance at 0:00, time to travel 90 degrees: 8 hours
next appearance at 0:00
3) speed = 2, daily increment = 0
appearance at 0:00, time to travel 90 degrees: 3 hours
next appearance at 0:00
4) speed = 2, daily increment = 1
appearance at 17:00, time to travel 90 degrees: 3 hours
next appearance at 18:00
5) speed = 1, daily increment = 1
appearance at 17:00, time to travel 90 degrees: 6 hours
next appearance at 18:00

It seems than speed is frequency and hour of appearance is incremented by daily increment each day. But as you can see, speed and daily increment doesn't influence each other as logic would dictate. Hour of appearance is fixed each day no matter how fast moon is going.

Next thing is that waxing and waning depends on the angle with the Sun. I think that vanilla is inspired by our moon but ... trajectory of Moon/Earth/Sun are very different to Masser/Secunda/Tamriel/Sun. Take a look at the picture - it doesn't really obeys any rules of physics, moons shouldn't be visible at all, if they are between Tamriel and Sun and if they are visible, they reflect sunbeams from wrong side. More over Masser appears 35 degrees left from north and Secunda 50 degrees so their angle with sunbeams completely change each day, right?

This is either one big dirty hack, or it is way beyond my logical reasoning. I think it would be very hard to replicate calculations based on fallback settings so I suggest to drop compatibility with fallback settings and keep at most default fallback settings. Second, original trajectory and waning/waxing isn't very obvious so its implementation will be probably pretty ugly and I doubt we will ever catch it. So I suggest we also drop original moon trajectory and create similar but one based on some reasonable mathematical model.

TES series doesn't pay too much attention to these details either, if you look at calendars for instance.

I've already tried pretty dirty implementation of original trajectory which would probably break with different fallback setting and one implementation based on 3 rotating vectors according to timeStamp. The second option is much more appealing to me since it allows further improvements...

Uhhh...

Not in favour of dropping fallbacks. It doesn't need to look better than original MW and it also does not need to be a pixel perfect match, but it should be reasonable close to it and it definitely should not be less configurable.

Developing new sky mechanics seems rather pointless to me. We would throw out the whole stuff anyway (but keeping the MW falback), once sky mechanics become modable. We could use said sky mechanics as a default for newly generated files in the CS, but we don't even know yet exactly how that will look. And modding people will come up with their own sky mechanics, so these defaults will not even be used in many cases. Waste of time at this point IMO.

I'm pro an astronomical rigthfullness,
it seems more realistic.
But that's just my point of view.

Of course. But what does "astronomical rigthfullness" mean here? A new system might work for MW, but it could easily screw up a TC that takes place in a complete different environment.

Any replacement system that does not mimic the original would fall into the category of content and we don't do that here (except for the example suite). Setting up sky mechanics falls into the area of modding, not engine development.