Daily Archives: June 21, 2021

To those of us who have been watching the Second Life blogosphere, the existence of the Environment Enhancement Project (EEP), which replaces Windlight, has been well-known for quite a while. After all, it’s been well-documented and extensively written about, and quite a few tutorials exist for it. Furthermore, after Firestorm’s 6.4.13.63251 release (regardless of people’s personal preference, Firestorm is the most popular third-party viewer for SL), practically every SL user now has the user interface to use EEP.

I won’t mince my words: I never liked the way the Sun looked in any of the existing windlights. Historically, the Sun in SL skies has always looked like a hexagon – blurry or relatively sharp. This made shooting sunsets or sunrises in SL a rather unappealing endeavour. Thankfully, EEP has allowed us to use our own textures for the Sun or the Moon. So, not only do we get to have a decent-looking sun in the sky, but also use a custom texture for a unique effect. As far as the Moon is concerned, we can depict a different moon phase simply by using a different texture. Also, EEP gives us the chance to set the duration of the day cycle. In these regards, EEP is considerably more powerful than Windlight’s implementation has been. However, there’s still room for improvement.

User-programmable Timers for Seasonal EEPs and daytime duration change

Consider a sim designer / owner who wishes to have a seasonal sim, with snow in the winter, different colours in the foliage for all the seasons, etc. They can add dedicated snow add-ons for various buildings and for terrain features. They can add icicles, apply different ground textures, and whatnot. However, this change won’t be complete without sky (and maybe even water) settings to match. Also, we know that, in RL, the duration of the daytime changes every day throughout the year, and this depends on the season and each location’s geographical latitude.

A contour plot of the hours of daylight as a function of latitude and day of the year.
A contour plot of the hours of daylight as a function of latitude and day of the year, using the most accurate models described in Sunrise equation. Latitude 40° N (approximately New York City, Madrid and Beijing) is highlighted for reference.Image credit: Cmglee on Wikipedia (original image here)

In RL, this change in daytime duration happens automatically as the earth rotates around itself and around the Sun. In SL, however, we don’t currently have a way to replicate this; instead, we need to do this by hand. Exactly the same applies to the change of seasons – we need to keep notes of when we want to change the season in our sim or parcel and, besides all the other work (changing trees’ textures accordingly, adding / removing snow caps and whatnot, water settings, and so on), we need to manually change the EEP day cycles. I believe there can be a better way. Namely, I’d like to see an enhancement to the current UI (I actually wouldn’t mind if it’d bring up a separate floater for this) that would allow the user to:

  1. Determine the duration and scheduling of the seasons (i.e. spring starts on date A and ends on date B; summer starts on date C and ends on date D; and so on);
  2. Determine a general day cycle for each particular season, which will be the prevalent day cycle;
  3. Determine whether the daytime duration should remain the same all through that particular season, or if they should change, as is the case in RL: if the user wants the daytime duration to change throughout the season, the system should allow the user to determine by how much (in minutes and seconds) and how often (in days).

Of course, the only way our ideas can stand a chance to become part of our SL experience is to submit them (in cases like this, as feature requests) to the Lab using its JIRA bug tracker, and this is precisely what I did. I filed a new feature request (BUG-230857), which I’ll be following closely and updating with further suggestions as to how such a UI could look and work.

Now, these are just the essential functions it should provide. There could be further enhancements; for instance, there could be an option to specify up to two or three extra sky and water settings to stand in as alternatives, so that the region or parcel could offer its visitors (regular or not) some sort of variety w.r.t. its weather. These alternative EEP settings could then be scheduled to appear in specific intervals, on specific dates, or even randomly.

User-programmable Moon Phases

The phases of the Moon as viewed looking southward from the Northern Hemisphere. Each phase would be rotated 180° if seen looking northward from the Southern Hemisphere. The upper part of the diagram is not to scale, as the Moon is much farther from Earth than shown here. Image credit: Orion 8 on Wikipedia (original image here)

In RL, we get to enjoy lunar (Moon) phases. Waxing or waning crescent or gibbous, new moon, full moon, blue moon, supermoon, even lunar eclipses. And not only that, there’s some variety even as the seasons change. So far, though, in SL, we haven’t had this pleasure. Only recently did EEP give us the chance to replace the default Moon texture with one of our choice. But still, it’s the same texture, and it doesn’t change as the days go by; we have to change it ourselves. So, I went and filed another feature request, specifically for this (BUG-230859). What I have in mind is an enhancement of the EEP UI to offer sim designer / owners the following abilities:

  1. Enable / disable moon phases – this could use the current EEP’s moon texture, overlaying a dark texture on it to depict how the moon looks in each phase;
  2. How often (in days) should the moon phase change;
  3. Inclination of the wax / wane texture’s Z-axis: so, it could be completely vertical, or at an angle (in degrees);
  4. Blue moons / Supermoons: The user should be able to determine the blue moon’s texture (which will override the current EEP’s moon texture), how much (in %) larger the supermoon should be in comparison to a regular full moon, and the timing of their appearance, i.e. how often (in increments of months, weeks, and days, i.e. X months, Y weeks, Z days) they should appear.

Even things like a 22° halo could be added, perhaps linked to the scheduling (specific or random) of a particular weather condition. Of course, since I filed these feature requests, I’m absolutely willing to help with ideas, even UI mock-ups.

Can you help?

Your feedback and ideas on these two JIRAs, as well as adding them to your watch list, would be greatly appreciated, as they would not only indicate interest from the user base, but could also offer ideas as to how these features can be implemented with a powerful, yet intuitive and easy-to-use, UI.