Misbehaving weathervane

[Rolig Loon]

Here's an annoying one.  I made a simple sculpty weathervane for my roof about a month ago.  It works just fine, but for some odd reason  it has flipped upside down (+Z for -Z) four or five times since I installed it.  I've never seen it happen, so I don't know what conditions make it do that.  Any ideas?

default
{
    state_entry()
    {
        llSetTimerEvent(4.0);
    }
    timer()
    {
        vector WindDir = llWind(ZERO_VECTOR);
        if((llFabs(WindDir.x) > 0.1) || (llFabs(WindDir.y) > 0.1))
        {
            llSetRot(llGetLocalRot()*llRotBetween( <1.0,0.0,0.0> *llGetLocalRot(), llVecNorm(<WindDir.x,WindDir.y,0.0>) ));
        }
    }
}

 

[Void Singer]

what do you get for llRotBetween( <1.0, 0.0, 0.0>, <-1.0, 0.0, 0.0> ) ?

I suspect that the rotation returned might not be on the z axis if it's near the complete opposite vector, and instead on the x axis occasionally, flipping the object.

[Kaluura Boa]

Second, I'd remove llGetLocalRot() from your formula.

But first, I wouldn't use llRotBetween() which doesn't work well in every situation.

 

default{    state_entry()    {        llSetTimerEvent(1.0);    }    timer()    {        vector wind = llWind(ZERO_VECTOR);        llSetRot(llEuler2Rot(<0.0, 0.0, llAtan2(wind.y, wind.x) + PI>));    }}

 My formula over here point the X axis of the prim toward the wind and I'm sure the prim will never turn upside down.

 

[Rolig Loon]

Aha... Good thought, Void. I hadn't considered that case.

Kaluura, I'll give your version a try. Thanks. I never would have thought of doing it that way. What do you mean by "llRotBetween() ... doesn't work well in every situation"?  Other than the fact that it always measures the angle that is less that 180 degrees between the two vectors -- thus making it hard to use if you want to get a compass heading, for example -- I wasn't aware of any situations when the function fails to work as advertized. 

[Qie Niangao]

Is there some reason we're avoiding llRotLookAt() ?

[Rolig Loon]

I wasn't necessarily avoiding it. I just wrote it the way that seemed most logical at the time.  Now I'm intrigued. Given the three options so far (llRotBetween, llRotLookAt, and Kaluura's method using llAtan), I can't see a good reason to favor one over the others.  What should I know that I am missing here?

[Qie Niangao]

Now that I actually look at the code, my weathervane script looks a lot like Kaluura's suggestion, with the relevant line being:

llRotLookAt(llEuler2Rot(<0,0,llAtan2(wind.y, wind.x)>), 1.0, 1.0);

It's not obvious to me why llRotBetween() is unstable, so Void's explanation sounds as good as any I'd dream up.

[Kaluura Boa]

I tried to retrieve why I didn't like llRotBetween() and now I know. It introduce some parasite rotation on one axis which leads to object to go upside down when the vectors used in the formula are opposite like <1.0, 0.0, 1.0> and <-1.0, 0.0, 1.0>... but not <1.0, 0.0, 0.0> and <-1.0, 0.0, 0.0>. In other words, it's quite unreliable and I'm also starting to wonder if the vector returned by llWind() has always z == 0. If not, that explains the upside down bug.

As for llRotLookAt(), I think it's a bit overkill if the object doesn't use physics. llSetRot() is well enough to follow the wind.

 

[Rolig Loon]

Interesting, Kaluura. I've been assuming that the vector returned by llWind always has its Z component == 0.0, although the wiki entry is dreadfully sparse and doesn't actually say so.  I'll try doing some tests to find out.

Thanks again.

[Rolig Loon]

For what it's worth, I have had the following script running in test objects on two sims since Wednesday.

list SaveWind;default{    state_entry()    {        llSetTimerEvent(1.0);    }    timer()    {        vector Wind = llWind(ZERO_VECTOR);        if (Wind.z != 0.0)        {            SaveWind += [(string)Wind];            llSetColor(<1.0,1.0,1.0>, ALL_SIDES);        }        if (llGetListLength(SaveWind) > 100)        {            llSetTimerEvent(0.0);        }    }                touch_start(integer total_number)    {        llSay(0, llDumpList2String(SaveWind,"\n"));    }}

 So far, in over 500,000 sampling events it hasn't detected a wind vector with a Z component.  I suspect that wind is always horizontal in SL.  It was worth testing, though.

[Void Singer]

it may not be safe to rely on that though... never know what changes may happen.

[Rolig Loon]

Yeah, that's always true.  For right now, though, it looks as if wind in SL doesn't have a vertical component.....  not that it matters for my little windvane.  I'm using Kaluura's suggestion instead, so I don't need to test for a vertical component any more.  I was just curious.