Float rate for pulsating glow?

[DAT4BASE]

Hey guys, so i'm trying to get a mesh to glow and i have thi script:

float rate = 1;

default
{
    state_entry()
    {            
            llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.001]);
            llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.01]);
            llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.02]);
            llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.03]);
            
            llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.05]);
            llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.05]);
            
            llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.03]);
            llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.02]);
            llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.01]);
            llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.001]);
            
            llResetScript();            
            
            }    
}

but for some reason the float rate isn't doing anything. it's not affecting the speed of thed animation. so i'm just wondering if someone can help me "fix" the code so that it does get affected by the speed? thanks !

[Madelaine McMasters]

"Rate" isn't doing anything because you never use it in your script. I'm going to guess that you want your thing to cycle its glow over time. That requires the introduction of time into your script. The simplest way to do this is to place llSleep(Rate) calls after every llSetPrimitiveParams() call. That will pause your script for "Rate" seconds at each call, giving you time to notice the changes in glow. llSetPrimitiveParams() has a built in sleep of 200ms, so your current script will cycle glow no faster than once every two seconds. To go faster, use llSetLinePrimitiveParamsFast() instead, using LINK_THIS for the link parameter. Most scripters avoid using llSleep() because it stops everything in the script, but if this is all you are doing, it's fine.

Your list of glow values contains two repeats, 0.001 and 0.05. You could eliminate two calls to llSetLinePrimitiveParamsFast() by simply doubling the sleep time after the first instance of each repeated glow value, but I think it's actually better to leave things as you have them in case you want to find tune the glow values and end up with no repeats.

Resetting the script at the end does cause the script to endlessly cycle, but I imagine that produces unnecessary load on the script engine as resetting a script involves a lot of overhead. I'd remove that line and encase the remainder inside a while(1){     };

Edited September 8, 2020 by Madelaine McMasters

[Rolig Loon]

Yes, as Maddy says, the basic problem is that you created a float variable for rate but you never used it (Incidentally, you created rate as a float variable and then you gave it an integer value, which is not going to fly.).  The second big problem, which she touched on, is that

28 minutes ago, Madelaine McMasters said:

Resetting the script at the end does cause the script to endlessly cycle, but I imagine that produces unnecessary load on the script engine as resetting a script involves a lot of overhead.

You really need an explicit timer event.  Do it right. Start a timer in state_entry with llSetTimerEvent(rate);  Then add a global counting variable to keep track of how many times you have triggered the timer.  Finally, rewrite your glow instructions to function in a regular sequence.  There are many ways to do this, some involving calculating a new glow intensity each time the trigger fires.  In your case, I think you'll save a lot of grief and load on the system by simply listing the intensity values in a list and calling a different one each time.  There are many ways to do even something as simple as this, but I'll write out one that takes up a little space but may be easier to follow than a slightly more elegant script would.  So ....

float rate = 1.0;
integer iCount;
list lGlows = [ 0.001, 0.01, 0.02, 0.03, 0.05, 0.05, 0.03, 0.02, 0.01, 0.001];

default
{
    state_entry()
    {
        llSetTimerEvent(rate);
    }

    timer()
    {
        llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, llList2Float(lGlows, iCount)]);
        ++iCount;
        if (iCount == 10)
        {
            iCount = 0;
        }
    }
}

We would not normally provide a full freebie script in this forum, but I think this little snippet can help introduce several fundamental scripting concepts.

        

Edited September 8, 2020 by Rolig Loon
typos. as always.

[DAT4BASE]

On 9/8/2020 at 5:48 PM, Rolig Loon said:

Yes, as Maddy says, the basic problem is that you created a float variable for rate but you never used it (Incidentally, you created rate as a float variable and then you gave it an integer value, which is not going to fly.).  The second big problem, which she touched on, is that

You really need an explicit timer event.  Do it right. Start a timer in state_entry with llSetTimerEvent(rate);  Then add a global counting variable to keep track of how many times you have triggered the timer.  Finally, rewrite your glow instructions to function in a regular sequence.  There are many ways to do this, some involving calculating a new glow intensity each time the trigger fires.  In your case, I think you'll save a lot of grief and load on the system by simply listing the intensity values in a list and calling a different one each time.  There are many ways to do even something as simple as this, but I'll write out one that takes up a little space but may be easier to follow than a slightly more elegant script would.  So ....

float rate = 1.0;
integer iCount;
list lGlows = [ 0.001, 0.01, 0.02, 0.03, 0.05, 0.05, 0.03, 0.02, 0.01, 0.001];

default
{
    state_entry()
    {
        llSetTimerEvent(rate);
    }

    timer()
    {
        llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, llList2Float(lGlows, iCount)]);
        ++iCount;
        if (iCount == 10)
        {
            iCount = 0;
        }
    }
}

We would not normally provide a full freebie script in this forum, but I think this little snippet can help introduce several fundamental scripting concepts.

        

thanks for this! it worked great, but for some reason it isn't as smooth as i originally tried to get it. you can really "see" the frame rate, if that makes sense? i wanted it to really look like it was pulsing. is that at all possible?

Edited September 10, 2020 by DAT4BASE

[Qie Niangao]

If the change is too slow, you'd want to decrease the value of the rate constant. If the change is the right speed but it should be "smoother" then the list of glow values would have to get longer, with more intermediate values, which would also entail a shorter rate to cover the full cycle in the same time, and the test for iCount would be the new length of that list instead of 10.

Using llSetPrimitiveParams, the rate can't get smaller than 0.2 -- for that, you'd need llSetLinkPrimitiveParamsFast() -- but 0.2 seconds is already a lot of script events, generating a heavy spew of object updates.

If we knew more about the object's texture and the desired effect, there may be less script-intensive options. For example, if the object happens to be uniformly textured (the "blank" texture), it might be a satisfactory substitute for pulsing glow to instead replace the texture with an alpha gradient, animate it, and set alpha mode to "emissive mask" to make the surface pulse from full-bright to normal (at least in viewers with Advance Lighting Model enabled). It's not glow, but it's a compelling "pulsing" light effect with no script events and no object updates at all -- if it happens to match the object's application.

[DAT4BASE]

5 minutes ago, Qie Niangao said:

If the change is too slow, you'd want to decrease the value of the rate constant. If the change is the right speed but it should be "smoother" then the list of glow values would have to get longer, with more intermediate values, which would also entail a shorter rate to cover the full cycle in the same time, and the test for iCount would be the new length of that list instead of 10.

Using llSetPrimitiveParams, the rate can't get smaller than 0.2 -- for that, you'd need llSetLinkPrimitiveParamsFast() -- but 0.2 seconds is already a lot of script events, generating a heavy spew of object updates.

If we knew more about the object's texture and the desired effect, there may be less script-intensive options. For example, if the object happens to be uniformly textured (the "blank" texture), it might be a satisfactory substitute for pulsing glow to instead replace the texture with an alpha gradient, animate it, and set alpha mode to "emissive mask" to make the surface pulse from full-bright to normal (at least in viewers with Advance Lighting Model enabled). It's not glow, but it's a compelling "pulsing" light effect with no script events and no object updates at all -- if it happens to match the object's application.

hmm, see i tried those two things, but it seems there's a minimum speed. I went down to 0.5 and it was still choppy, so i went even lower and effectively stopped noticing any change. I also tried the intermediate values and upping the icount, but it really also wasn't much smoother.

I'm trying it both on my mesh logo and on a simple green glowing square prim. Both are choppy

thanks so much for your advice tho!

[Rolig Loon]

1 hour ago, Qie Niangao said:

For example, if the object happens to be uniformly textured (the "blank" texture), it might be a satisfactory substitute for pulsing glow to instead replace the texture with an alpha gradient, animate it, and set alpha mode to "emissive mask" to make the surface pulse from full-bright to normal (at least in viewers with Advance Lighting Model enabled). It's not glow, but it's a compelling "pulsing" light effect with no script events and no object updates at all -- if it happens to match the object's application.

That's a very effective technique.  It essentially involves making FULLBRIGHT pulse gradually from 0% to 100% rather than simply switching between OFF and ON. Using llSetTextureAnim means that you can cut out the need for a timer.  As you point out, it's only practical if the object has a uniform texture, but that's fine if the object is, say, a light bulb.

[Rachel1206]

1 hour ago, DAT4BASE said:

hmm, see i tried those two things, but it seems there's a minimum speed. I went down to 0.5 and it was still choppy, so i went even lower and effectively stopped noticing any change. I also tried the intermediate values and upping the icount, but it really also wasn't much smoother.

I'm trying it both on my mesh logo and on a simple green glowing square prim. Both are choppy

thanks so much for your advice tho!

Simple conditions as the color you are using combined with color(s) or your mesh object have effect on the how well the glow is shown. And glow value of <0.01 are really hardly visible normally.

Along sameline, how large is the part of the mesh object - small narrow would require larger glow values to be good visible - larger the other way around. Again color combinations have effect. Last but no least - if slow script run in a region, this will delay anything and very clear on an object with glows, either with sudden jumps on intensity.

Using llSetLinkPrimitiveParamsFast something like this along same procedure as @Rolig Loon showed:

integer nCount;
list lGlows = [ 0.01, 0.03, 0.08, 0.16, 0.3, 0.5, 0.3, 0.16, 0.08, 0.03, 0.01];
float fGlow;

default
{
    state_entry()
    {
        llSetLinkPrimitiveParamsFast(LINK_THIS,
        [
            PRIM_COLOR, ALL_SIDES, <1.000, 0.000, 0.502>, 1.0
        ]);
        llSetTimerEvent(0.250);
    }

    timer()
    {
        fGlow= llList2Float(lGlows, nCount);
        
        llSetLinkPrimitiveParamsFast(LINK_THIS,
        [
            PRIM_GLOW,
            ALL_SIDES,
            fGlow
        ]);

        ++nCount;
        if (nCount>11)
            nCount = 0;
    }
}

[DAT4BASE]

28 minutes ago, Rachel1206 said:

Simple conditions as the color you are using combined with color(s) or your mesh object have effect on the how well the glow is shown. And glow value of <0.01 are really hardly visible normally.

Along sameline, how large is the part of the mesh object - small narrow would require larger glow values to be good visible - larger the other way around. Again color combinations have effect. Last but no least - if slow script run in a region, this will delay anything and very clear on an object with glows, either with sudden jumps on intensity.

Using llSetLinkPrimitiveParamsFast something like this along same procedure as @Rolig Loon showed:

integer nCount;
list lGlows = [ 0.01, 0.03, 0.08, 0.16, 0.3, 0.5, 0.3, 0.16, 0.08, 0.03, 0.01];
float fGlow;

default
{
    state_entry()
    {
        llSetLinkPrimitiveParamsFast(LINK_THIS,
        [
            PRIM_COLOR, ALL_SIDES, <1.000, 0.000, 0.502>, 1.0
        ]);
        llSetTimerEvent(0.250);
    }

    timer()
    {
        fGlow= llList2Float(lGlows, nCount);
        
        llSetLinkPrimitiveParamsFast(LINK_THIS,
        [
            PRIM_GLOW,
            ALL_SIDES,
            fGlow
        ]);

        ++nCount;
        if (nCount>11)
            nCount = 0;
    }
}

this worked like a charm, but for some reason now my mesh is hot pink? is that intentional?

 

edit: my non-scripter brain finally figured out that PRIM_COLOR, ALL_SIDES, <1.000, 0.000, 0.502>, 1.0 determines the colour. i guess that resolved it then? the glow is pretty bright though, but i'll play around with it to get something a little more subtle. thanks so much!

Edited September 10, 2020 by DAT4BASE

[Rachel1206]

1 hour ago, DAT4BASE said:

this worked like a charm, but for some reason now my mesh is hot pink? is that intentional?

 

edit: my non-scripter brain finally figured out that PRIM_COLOR, ALL_SIDES, <1.000, 0.000, 0.502>, 1.0 determines the colour. i guess that resolved it then? the glow is pretty bright though, but i'll play around with it to get something a little more subtle. thanks so much!

Yes the use of a color, to show you how glow change with another color - as with the strength of the glow, adjust to your mesh object, experiment with values. Max glow value of 0.3 for more subtle changes. For full bling Las Vegas style 0.8-1.0!