Advice on working with Sun Position

Hi!

I'm trying to work out something simple that will rez an item when its dark out, and llDie() it when its light out. (In terms of sim sun position - I understand clients can override).

The mechanics of rezzing & Die'ing are no prob. Got that down. What I'm stumped on, is the proper use of llGetSunDirection(), or if that's even the proper function call I should use for this application.

The Wiki doesn't seem to explain a whole lot, and doesn't give any example code for me to work off of. Apparently, this function returns a vector - the application of which confuses me.

Additionally, the Wiki references a table of sun position that seems to be incorrect. According to the table, 12:00pm SL time should be somewhere between Sunrise & Sunset (Daytime). However - without changing my client - the sun position on the mainland at 12:00pm SL time appears to still be evening.

I'm stuck in a ball of confusion. Could anyone out there explain things a little better - and maybe post some example code using llGetSunDirection() that'd help make some sense?

Thanks in advance for the help!

Travis,
I was in this quandary just a couple weeks ago. llGetSunDirection will return a vector, i.e. <0.0,0.0,0.0>. If you are concrerned w/ Daytime and Nighttime events, you are looking for the .z position to be near zero: <x.x, x.x, 0.0>. I am still searching for more efficient ways to do such a thing, or any secrets to being more accurate, but this is the way I handled it.

I set a timer event to check the sun position every 600 seconds (10 minutes):

For sunrise:

    vector sun = llGetSunDirection();
        
    if((sun.z < 0.1) && (sun.z > -0.1) && (sun.x > 0.0))
    {
         do something;
     }

For sunset:

    vector sun = llGetSunDirection();
        
    if((sun.z < 0.1) && (sun.z > -0.1) && (sun.x < 0.0))
    {
        do something;
    }

You of course could combine those two snippets w/ an ELSE IF statement. I just happened to copy/paste from two separate scripts.

I'm still trying to be more accurate, I've IM'ed a few people about the matter. I went so far as to track the sun position to sim time every minute over a 4 hour period (a sim day.) I'm still not completely sure about the sun orbit, but the above variables seem to give enough leeway to a 10 min. timer.

I don't see why you're checking the x position of the vector....

You don't need to check whether the sun's z is in a certain range - all you need to do is compare it to the last one to see whether you have reached sundown. You can do this with a global or with states.

e.g.

state default
{
   // blah de blah other things, set a timer at some point please
   timer()
   {
      vector sun = llGetSunDirection();
      if (sun.z < 0) state night;
   }
}

state night
{
   state_entry()
   {
      // various things to do when night falls
   }

   timer()
   {
      vector sun = llGetSunDirection();
      if (sun.z > 0) state default;
   }
}

Yep, Ordinal is right. Sorry, in my script I needed an event to trigger at sunrise, and only at sunrise. Not a simple rez or no rez state.

So basically, Travis, you're looking for .z to be greater than 0.0 for daytime and less than 0.0 for night.

And yeah, Travis, that wiki table is incorrect. I'm sure it's due to grid shutdowns over time, etc.

Ugh, I hope Travis isn't inworld now wondering why his object is derezzing 10 minutes later

Not sure if this'll do what you want, but I'm triggering a script at sunrise
by checking the time. I use llGetGMTclock to find the hour and minute:

http://secondlife.com/badgeo/wakka.php?wakka=llGetGMTclock

then use the table here. It seemed pretty accurate to me.

http://secondlife.com/badgeo/wakka.php?wakka=llGetSunDirection

So I have a block like:

integer gmt = (integer)llGetGMTclock();

integer hours = gmt / 3600;
integer minutes = (gmt % 3600) / 60;

if (minutes == 30)
{
    if (hour == 3 || hour == 7 || hour == 11 || hour == 15 || hour == 19 || hour == 23)
    {
         // cock-a-doodle-doo
    }
}

I make (and very occasionally sell) a lighthouse light that turns itself on and off in precisely the way you want.

Ordinal's method is the one I use pretty much. It works wonderfully.

Alphazero, that table isn't accurate. It may have been close to accurate at the time you checked, but it can be way off over time. Your rooster could be cock-a-doodle dooing at midnight. llGetSunDirection is the way to go.

Well, there's always llGetTimeOfDay() too... since SL day/night cycle lasts 4 hours it's quite easy to figure out from it what the in-sim hour is supposed to be.

Figure it'll go awry in sims with locked sun position, though. But then it such sims there's little point in scripts that operate on day/night cycle, too.

Once again - you guys rock!

Thank you - I've escaped my ball of confusion, and am on my way to making this work

And now if you do a scripting forum search on llGetSunDirection(), a result actually comes up now

Hopefully I wont be the last one that this thread helps.


A million thanks!

Joannah, tis true, but it will also go awry in the first 4 hours after a sim reset or shutdown. The llGetSunDirection guarantees the script will be accurate whenever.

Ahh indeed, i didn't read the description close enough and presumed when the sim is reset it starts with sun put at midnight position (to keep the results of gettime() reliable) ... bit odd it's not the case, actually :<

Yeah, that's because the sun is in the same position grid-wide (aside from islands w/ a set sun position.) That way it remains constant when you cross sim borders. I don't know why the time of day wouldn't just reset according to the sun, but I'm sure there's a reason for it.

Huh. How 'bout that.

.z it is. Thanks!

Okay, so let's say I've read this helpful thread. I now have an object that emits light at night and turns it off during the day, BUT I would like the light to come on a little earlier than (sun.z < 0) would normally trigger it, and a little later than (sun.z > 0) would shut it off.

In other words, I'd like the light to come on at "dusk," and linger a bit into "dawn" before shutting off.

Any of you fine folks have a ballpark estimate of what those values might be? Would a value like (sun.z < 0.1) work to kick the light on a little sooner? I'd test this myself, but waiting for the sun to go down tends to get tedious (and force sunset doesn't affect the script).

With a z of .1, the sun will be about 6 degrees above the horizon. Just find the sin of whatever angle you want it to be above or below the horizon to find the proper z.

God I hate math.

Thanks for the help, Keknehv. Six degrees sounds like a good starting point, I'll give that a whirl and adjust from there.

Let´s invent llSunFlower(vector sunposition);

ok, I've been working the last few days with variations of:

(llRot2Euler(llRotBetween(llGetSunDirection(),llGetPos())) * RAD_TO_DEG)

and

(llGetSunDirection() * RAD_TO_DEG)

My goal was to come up with some kind of way of getting:

Sun up: 0 degress
Noon : 90 degress
Sun down: 180 degrees
Midnight : 270 degrees

and, of course, finding various angles between those times.


Now the first bit of code seems to do well till just before sunset, then the results get unpredictable. The second bit of code handles sun up and sun down well, but doesn't do so well with noon or midnight.

This has about driven me off my rocker and any help would be greatly appreciated.

Thinking back to when I tried making a sundial and at work just now so can't check this until later </disclaimer>

If I recall correctly the vector returned from llGetSunDirection() is a normalised vector, i.e. the three components added together equals 1 (vec.x + vec.y + vec.z = 1) WRONG, Sorry, my maths is a little rusty, a normalised vector results in a vector of length equal to 1 so by pythagoras we have x^2 + y^2 + z^2 = 1^2. We're looking at the z-component and judging it's value over time, the magnitude of the z-component isn't only dependant on the suns height in the sky but also it's position since x and y are changing with time. [perhaps it's the mod of vec.x + mod(vec.y) + mod(vec.z) = 1 as the values can be negative]

Making sense so far?

Therefore the sun's height isn't a (0 to 1) or (-1 to 1) value. So how do we use this? I'm afraid the answer is down to maths *scratches head*, wish I'd paid more attention to the 3D geometry and trig stuff in maths class.

Do we know if the sun follows a rigid path? i.e. the 'orbit' doesn't change unlike the real sun which changes the seasons (or even the earths tilt relative to the sun).

I think I'll need to set up a data-logger to capture the position of the sun over a 4-hour cycle and then another to watch it over a week or longer to see if it shifts from the first recorded cycle.

Edit:


You'll find that llGetPos() will not be needed in your calculations, the suns position is constant no matter where you are in a sim and I believe it is constant accross the mainland (although never tested this theory).

Perhaps try using llRotBetween(llGetSunDirection(),<1,0,0>

e.g.

vector sun_rot = llRot2Euler(llRotBetween(llGetSunDirection(),<1,0,0>)); // * RAD_TO_DEG if you wish.

Edit 2
text in red is wrong, replaced with blue (my maths is getting rusty).

I believe it does, I am lucky enough to be on estate for a sim (so I can control the time of day) and got these numbers, I expect more are needed. However, it is a start.

Good Job Armandi, though I think I'll throw together a simple datalogger and grab a chunk of data, just for the hell of it. Then try and plot a pretty picture in MATLAB or something, see how it turns out. As for the tilting, I would highly doubt that the sun shifts it's path through the sky from day to day.

One thing I forgot to mention was that as the sun approaches the horizon (setting or about to rise) the z-component will drop towards zero (or rise towards zero) but this isn't likely to be linear. I can't quite get my head around how to approach this at the moment and would much rather have a shot at it from within SL using LSL or try simulating the maths surrounding it in MATLAB or similar (if I can still remember how to use it). In any event this is an interesting topic and one I had intended to come back to (after attempting a sundial. I had realised that the z-component wasn't linear when I started using it, or the sine/cosine/tangent of it, for the length of the shadow).

Enough of my rambling, the end [of the working day] is nigh!

edit: text in red is wrong (see post below)

I did this a while ago. Caught the sun's positions in two different sims every 10 minutes for a Rl day.

The sun doesn't follow the same path every SL day I'm afraid, not even the same path in different sims...

There's a sort of offset and multiplied sine wave thing going on with the x, y and z values, plus some "noise" on top - the noise seems to be the simwise variation, as the graphs I got lined up pretty much except the chatter.

Sorry, I didn't keep all the data, so if someone wants to go and do it all again I won't complain.

The following are graphs of the x, y and z components of llGetSunDirection() over 24 hours (from midnight to midnight GMT 30/07/2006). I'm still grabbing data which I intend to use to determine some of the longer term functions at play (which don't show up as well on these graphs, namely a variation in amplitude of the waves over time).

Amazing graphs. There's even a scary suggestion of seasonal change in those orbits. Crikey, this is like the early days of astonomy! Wish they'd just give us the rules and save us the pain!!!!!!!