llGetEnvironment (+ related functions) return inaccurate unit vectors for sun / moon position
tracked
Quinn Elara
Rez a box, place this script inside of it:
default
{
state_entry()
{
llSay(0, "Hello, Avatar!");
}
touch_start(integer total_number)
{
list env = llGetEnvironment(llGetPos(),[SKY_LIGHT,SKY_SUN,SKY_MOON]);
vector spDir = llGetSunDirection();
vector rpDir = llGetRegionSunDirection();
vector envDir = llList2Vector(env,0);
quaternion rot;
rot = llRotBetween(llRot2Up(ZERO_ROTATION),envDir);
//rot = llAxisAngle2Rot(<0,1,0>,90
DEG_TO_RAD)
llGetSunRotation();llSetRot(rot);
llSay(0, "sunDir: " + (string)spDir + "\nenvDir: " + (string)envDir + "\nrpSunDir: " + (string)rpDir);
}
}
Click the box.
Observe that the prim will rotate towards the celestial body, however it does not point directly towards the body, with varying error levels.
Photo Viewer
View photos in a modal
Log In
IceCold Skytower
I have experienced this issue myself as well, in Foxtown RP at Riddings, my dynamic weather system that works by setting windlight sky doesnt behave well with the automatic street lighting that meant to turn on after sunset, and turn off after sunrise.
Maestro Linden
marked this post as
tracked
Maestro Linden
Quinn Elara: Ok, I'm at the point where I can reproduce this pretty readily. It seems that something as basic as changing a parcel from region EEP to parcel EEP by customizing a single setting can cause the sun and moon phases to be totally different (like >60 degrees), when they should be the same.
Importing this issue with that in mind.
Quinn Elara
Okay, I believe I have found what triggers the sun / moon tracking loss. It seems that whenever a keyframe in the EEP is hit, the tracking is lost and the value reported then lags behind by 1 keyframe, meaning the value reported is effectively behind the live environment by 2 (EEP) hours in my EEP. Whenever the parcel is reset to the region environment, then back to my EEP, the tracking will remain accurate between the current keyframes, but will be lost whenever the next keyframe is hit.
Quinn Elara
Having done some monitoring on this, it seems like tracking is lost just before midnight, at approx. 99.97% day progress according to Rider's sundial. Using my EEP (which Maestro has a copy of, "PBR - Saberhagen v155 IBL KHRNeutral / ACES AP1 Exp. 1.0"), the reported moon (or sun) position will jump from it's correct position to a wildly incorrect one, and does not return
unless
the parcel is set back to the region environment, and the EEP is re-applied. I was also timing how long it took from me performing a reset (setting the parcel to region environment and back to my EEP) until the tracking was lost (at midnight), which took 7m42s. Monitoring for a second time, tracking was lost at 8 AM (EEP time) or 33.42%, which took 846 seconds since the last time the EEP was reset. For the 3rd time around, tracking was lost at 10:10 (EEP time) , or 42.37%, with 799 seconds since last reset, with the angle jumping by 0.532251 (as measured by llAngleBetween). For the 3rd result, tracking was lost at 14:01 (EEP time), or 58.42%, with 469 seconds since last reset, with a measured angle jump of 1.037482 .I have a tool set up on my parcel which automatically monitors the sun / moon positions, and monitors if they are at the expected (on track) positions, and will notify when they jump off track, which is how I have collected most of this data.
EDIT: To add to the above, tracking was again lost at 16:04 (EEP time) or 66.97%, with 997 seconds since last reset, with the angle jumping by 0.790923. The next tracking lost happened at 17:59 (EEP time) or 74.95%, with 1041 seconds since last reset, with the angle jumping by 0.558547. After that, tracking was lost again at 19:53 (EEP time) or 82.88%, with 1059 seconds since last reset, with the angle jumping by 0.492431. Next loss was at 20:51 (EEP time), or 86.90% with 444 seconds since last reset, with an angle jump of 0.234945
A particularly bad track loss happened at 22:04 (EEP time), or 91.97% with 411 seconds since last reset, with a giant angle jump of 2.887990 , with the returned ambient color also being wildly incorrect.
The last track loss during this day cycle happened at midnight, (23:59 EEP time, 99.96%) with 1025 seconds since last reset, with an angle jump of 0.701312
Maestro Linden
marked this post as
needs info
Maestro Linden
I think this is bug is a matter of the viewer rendering the sun at the wrong place rather than the sim being incorrect about the time of day, since the simulator is the source of truth about EEP time of day. The viewer also offers some estimate of the time of day in the environment settings (with sunrise at 6:00AM and sunset at 6:00PM) - that would be another good thing to check for comparison.
That said, I'm still having trouble reproducing this. I visited my default day cycle region and found that the needle is still pointing at the direction the sun renders when 'use shared environment' is enabled in the viewer.
When you see a big difference between where the needle points and where the sun renders, had your viewer been in the region for a while? Also, does the sun continue to render in the same/incorrect location after you relog?
Quinn Elara
Maestro Linden Time spent in the region by the viewer seems to have no effect - Here's an image at a fresh relog.
My little EEP debugger also outputs the EEP time percentage, and shows that while it's receiving the correct time of day values from the simulator, the sun direction / rotation are definitely wrong. Image attached.
Debugger location: http://maps.secondlife.com/secondlife/May%20Queen/146/43/52
Photo Viewer
View photos in a modal
Maestro Linden
Quinn Elara: Thanks for the info. I've visited your parcel and see the incongruity that you see between where the viewer renders the sun and where LSL scripts think the sun is.
I did some digging and narrowed down the issue. It seems to stem from the custom EEP settings in your parcel, which seem to be distinct from the region-wide settings. I have updated the test script (updated in my comment) so that it can optionally query the region-wide EEP settings rather than parcel.
Another helpful piece of test content for this bug is the "EEP Sundial" that Rider Linden sells, which shows both the parcel and region moon settings:
On your parcel, it illustrates the difference between parcel and region sun/moon positions. When I move the sundial into the adjacent parcel, I see perfect alignment.
I see that while apparent time-of-day agrees between parcel and region EEP (both have 4 hour days with a -8 hour offset), there is about a several-degree difference in the sun position at any given moment. Sometimes, the difference is about 60 degrees, but other times, the difference appears to be more in the 15 degree range.
Looking at the Sun positions in the
parcel
day cycle view (About Land -> Environment -> Customize):Keyframe 1: Azimuth 270, Elevation -90
Keyframe 2: Azimuth 0, Elevation -45
Keyframe 3: Azimuth 0, Elevation 5.4
Keyframe 4: Azimuth 0, Elevation 45
Keyframe 5: Azimuth 270, Elevation 90
Keyframe 6: Azimuth 180, Elevation 45
Keyframe 7: Azimuth 180, Elevation 4.32
Keyframe 8: Azimuth 180, Elevation -45
When I check the
region
day cycle view (World -> Region/Estate -> Environment -> Customize), the keyframe positions of the sun are 100% identical to the parcel view.The keyframe positions within the day cycle look the same. Since the keyframe values and basic day cycle settings (day length and offset) all appear identical in the viewer, it looks like either
1) the viewer isn't displaying or rendering the custom parcel settings properly
2) the LSL functions are resolving bogus sun and moon values somehow - but only for your parcel
Quinn Elara
Maestro Linden Near as I can tell it has to be option 2, as previewing the EEP at any given percentage seems to put the sun / moon in the expected position, but the LSL return would place it considerably off-track. I've tried to reset the parcel to the region settings, and then re-apply my custom EEP, which fixes the problem, but only temporarily, as within 10 minutes the values are wrong again.
Photo Viewer
View photos in a modal
Maestro Linden
Hi Quinn, I'm having trouble reproducing this issue on Second Life Release 7.1.10.10800445603 and SLS 2024-11-25.12013542687.
I set up my own test script (attached in child comment) which rotates the object to directly point at the sun based on the rotation returned by SKY_SUN. When I run the script and sit on the object, the sun always appears in the center at the point of the needle, (see screenshot). My test area is set up to use the default sky and day cycle. I disabled cloud rendering in the viewer to make the sun position clearer.
Are you seeing different behavior with my test script? If so, do you see misaligned results when using the default day cycle?
Photo Viewer
View photos in a modal
Maestro Linden
Edit 1: script now includes virtual time of day of day cycle
Edit 2: script now contains 'useRegionEnv' boolean parameter to toggle whether parcel or region EEP settings are queried
// Whether to look up EEP settings at the parcel or region scope
integer useRegionEnv = FALSE;
default
{
state_entry()
{
// make the prim a narrow cone with +z as the point
llSetPrimitiveParams([PRIM_SIZE, <0.5, 0.5, 64>,
PRIM_TYPE, 1, 0, <0, 1, 0>, 0, <0, 0, 0>, <0, 0, 0>, <0, 0, 0>,
PRIM_SIT_TARGET, TRUE, <0,0,0.001>, llEuler2Rot(<0,-PI_BY_TWO, 0>)
]);
llSetCameraAtOffset(<-1,0,2>);
llSetCameraEyeOffset(<-1,0,1>);
llSetTimerEvent(1);
}
timer()
{
vector sunDir = llGetSunDirection();
// the first param of SKY_SUN is:
// rot: The current rotation applied to the sun.
vector pos = llGetPos();
string locationLabel = "\nParcel EEP settings at " + (string)pos;
if(useRegionEnv)
{
// special coordinates for region-wide EEP settings query at object's elevation
pos = <-1, -1, pos.z>;
locationLabel = "\nRegion EEP settings at " + (string)pos;
}
list env = llGetEnvironment(pos, [SKY_SUN, ENVIRONMENT_DAYINFO]);
rotation sunRot = llList2Rot(env, 0);
float dayLengthSeconds = llList2Float(env, 7);
float secondsSinceMidnight = llList2Float(env, 9);
//llSay(0, "Seconds " + (string) secondsSinceMidnight + " length " + (string)dayLengthSeconds);
// keep a 24 'hour' day even though day length probably isn't 24*3600 seconds
float dayPhase = secondsSinceMidnight / dayLengthSeconds;
integer hour = (integer)(dayPhase * 24.0);
// add 100 as a text formatting hack so that leading zeros always appear
integer minute = 100 + (integer)((dayPhase - (float)hour / 24.0) * 24.0 * 60.0);
llSetText(llGetTimestamp() + locationLabel
+ "\nllGetSunDirection() = " + (string)sunDir
+ "\nSun Rot Fwd = " + (string)llRot2Fwd(sunRot)
+ "\nVirtual Time = " + (string)hour + ":" + (string)llGetSubString((string)minute, -2, -1), <1,1,1>, 1);
//llSetRot(llRotBetween(<0,0,1>, sunDir));
//llSetRot(sunRot);
llSetRot(llEuler2Rot(<0,PI_BY_TWO, 0>) * sunRot);
}
}
Quinn Elara
Maestro Linden Strangely, setting the parcel environment to the default and then back to my custom EEP seems to have entirely fixed the problem. I wonder if there's an issue where the value drifts over time, eventually becoming inaccurate?
Photo Viewer
View photos in a modal
Quinn Elara
Maestro Linden And now the data is inaccurate again. The EEP I am using can be collected from a box here: http://maps.secondlife.com/secondlife/May%20Queen/143/43/52
Photo Viewer
View photos in a modal
Quinn Elara
Also repros on the default day cycle when applied to the parcel
Photo Viewer
View photos in a modal