Jump to content
LucidiaErsatz

TextureAnimation on Object funky during Movement.

Recommended Posts

Hello,

Sorry to trouble/disturb anyone but I've encountered an issue and Googling hasn't helped much. Would like to ask if anyone knows the reason for this 'error' or perhaps could point me in the right direction which I could look for answers. Would really really appreciate it. ?

I made a mesh object that simulates animation using llSetTextureAnim, (4 frames, 2 by 2) and cycles through the four frames of mesh, giving the illusion that the object 'Jumps'. The object animates without any issue when stationary. However when I script it to wander about, there are instances (random) where the texture / textureAnimation gets funky and freezes at the botched up state as it moves from point A to point B.

For movement (from Point A to B) I have tried using: 
1. llSetKeyframedMotion  
2. llMoveToTarget 

methods individually with both yielding the same results. Is there anything i could do to reduce the instances of it happening (if not) solve it? Have summarised the scripting but it is essentially a combination of llSetTextureAnim (to simulate a upward jumping motion) and llMoveToTarget + llLookAt to move forward and give the illusion of jumping forwards. 

 

Things I have tried that didn't work:
> placing llSetTextureAnim in not_at_target event hoping it would fire and over write the issue
> placing llEventDelay just before llMoveToTarget (as advised by someone else)



I have tried asking in a group in-world with someone mentioning that it is likely a server to client issue. Is there anything I could do on my side regarding this issue? 

Best Regards,
Lucidia.

Edited by LucidiaErsatz
adding further details

Share this post


Link to post
Share on other sites
1 hour ago, LucidiaErsatz said:

I have tried asking in a group in-world with someone mentioning that it is likely a server to client issue. Is there anything I could do on my side regarding this issue?

A texture animation is started by a script but once it's running, it's purely client side. So unless your scripts keeps restarting the animation, it has to be a problem in the viewer.

If the script is restarting the animation, you need to change that. Put the llSetTextureAnim() function is the State:Entry() event or somewhere else where it will only be triggered once.

If not, the most likely explanation is that the combination of moving object with changing texture is a bit to complicated for the viewer to handle.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Just now, ChinRey said:

A texture animation is started by a script but once it's running, it's purely client side. So unless your scripts keeps restarting the animation, it has to be a problem in the viewer.

If the script is restarting the animation, you need to change that. Put the llSetTextureAnim() function is the State:Entry() event or somewhere else where it will only be triggered once.

 

Thanks!! mmm, was originally only at the State:Entry() part, will keep it there. 

Bummer.. that the TextureAnimation + a movement results in that. I've always thought that out of all the ways to animate a mesh, TextureAnimation would be one of the more ideal methods.. I guess each method has their own problems. 

Thanks so much again!! ?

Share this post


Link to post
Share on other sites
4 minutes ago, LucidiaErsatz said:

Bummer.. that the TextureAnimation + a movement results in that. I've always thought that out of all the ways to animate a mesh, TextureAnimation would be one of the more ideal methods.. I guess each method has their own problems.

Remember that the most likely explanation isn't always the right one. Let's see if others have better ideas.

But I suggest you report the thread to the moderators and ask them to move it to the scripting forum. You may get more help there.

 

Edited by ChinRey
  • Thanks 1

Share this post


Link to post
Share on other sites
2 minutes ago, ChinRey said:

But I suggest you report the thread to the moderators and ask them to move it to the scripting forum. You may get more help there.

 

Ok, will do!! (Had to look around for the report button). Thanks again! ?

Hopefully there is something that can be done on my side other than to live with it. 

Share this post


Link to post
Share on other sites

Unable to edit the post as it's over 24 hours. ? 

Would like to add on to the post (additonal information for any documentation of sorts) on how to recreate the issue with a simple cube and a animated texture. 

1. Rez a cube 
2. Insert the script below. [Note: I used a timer () in this recreation but using a at_target will replicate it as well] [Any texture can be used]
3. Set Object to be Physical and Phantom (optional)

4. There will be moments where the Texture animations just freezes up and the texture is displayed incorrectly (unlike any of the four cells)
(more specifically, the same appearance as having a non-animated texture with Horizontal scale: 0.25, Vertical scale: 0.25, Horizontal Offset: 0.375, Vertical Offset: 0.375.)

vector oriPos; 

default
{
    state_entry()
    {
        llSetLinkPrimitiveParams (LINK_THIS, [PRIM_TEXTURE, ALL_SIDES, "c3187dbc-fbad-0544-f137-7568530451a9", <1.0, 1.0, 0>, ZERO_VECTOR, 0] );
        llSetTextureAnim( ANIM_ON | LOOP, ALL_SIDES, 2, 2, 0.0, 4.0, 5.0 );

        oriPos = llGetPos();
        llSetTimerEvent (4.0);
    }
    
    timer ()
    {
        llMoveToTarget ( 
        (<oriPos.x + llFrand(3.0), 
        oriPos.y + llFrand(3.0), 
        oriPos.z>), 4.0 );
        
        llSetTimerEvent (8.0);
    }
}

 

Edited by LucidiaErsatz
  • Like 2

Share this post


Link to post
Share on other sites

I can repro that on both the LL viewer & Firestorm.

I suspect it may be related to BUG-4455 - Scripts using llSetTextureAnim and floating text changing on a timer causes objects texture to flash. Additionally if texture uses non default repeats, texture repeats randomly reset

Note Maestro said in the comments that the bug was basically "full object updates cause texture animations to be reset to the first frame."

Really not sure though because the texture animation freezing on your repro cube does not appear to correspond with a full object update,

I think this should be filed on the JIRA though, it's a nice repro.
If you don't want to file a JIRA issue, let me know & I'll file one.

  • Thanks 2

Share this post


Link to post
Share on other sites
1 hour ago, Whirly Fizzle said:

 

I suspect it may be related to BUG-4455 - Scripts using llSetTextureAnim and floating text changing on a timer causes objects texture to flash. Additionally if texture uses non default repeats, texture repeats randomly reset

Note Maestro said in the comments that the bug was basically "full object updates cause texture animations to be reset to the first frame."

Really not sure though because the texture animation freezing on your repro cube does not appear to correspond with a full object update,

I think this should be filed on the JIRA though, it's a nice repro.
If you don't want to file a JIRA issue, let me know & I'll file one.

Thanks thanks!! I haven't seen that link yet, will do and read through it to get a better understanding too. 

Will do as you suggest  and attempt to file it on JIRA, (haven't done it before but will figure it out ?). Does the issue usually get resolved once it's on JIRA (just curious)? 

Further edit:
Have posted on JIRA as advised, 
https://jira.secondlife.com/browse/BUG-225792

Edited by LucidiaErsatz
  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, LucidiaErsatz said:

Does the issue usually get resolved once it's on JIRA (just curious)? 

That depends on a number of factors: whether the bug is a show-stopper or merely an annoyance, how difficult it may be to fix (and what else might be broken by the fix), who has time to work on a solution, and whether it's really a bug or "expected behavior," to state a few of the more obvious ones.  Some issues have been in the JIRA and unresolved for years.  Others are resolved within days.  The work flow within Linden Lab is similar to most organizations.  A task has to be prioritized and assigned to someone's attention first.  Then, assuming that it can be resolved, the solution needs to be thoroughly tested to be sure that it works and hasn't created other problems.  Companies don't have unlimited resources, and low-priority tasks can be lost in the cloud of more pressing issues, so it's hard to say how long it "usually" takes for a report to work through the pipeline.

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, LucidiaErsatz said:

Does the issue usually get resolved once it's on JIRA (just curious)? 

If it's a bone fide bug, yes, eventually.

 

  • Like 2

Share this post


Link to post
Share on other sites
On 11/11/2018 at 4:26 AM, Whirly Fizzle said:

If it's a bone fide bug, yes, eventually.

 

 

On 11/11/2018 at 4:25 AM, Rolig Loon said:

That depends on a number of factors: whether the bug is a show-stopper or merely an annoyance, how difficult it may be to fix (and what else might be broken by the fix), who has time to work on a solution, and whether it's really a bug or "expected behavior," to state a few of the more obvious ones.  Some issues have been in the JIRA and unresolved for years.  Others are resolved within days.  


I see I see, thanks for the response ?, and really good to know that it does get looked into and that it may get resolved / looked into.

 

On 11/11/2018 at 2:39 AM, Whirly Fizzle said:

Note Maestro said in the comments that the bug was basically "full object updates cause texture animations to be reset to the first frame."

Ah, saw the link provided and that comment (by Maestro) as mentioned. Thanks again!! ? I added a crude 'workaround' (sort of) to try and minimise the times the TextureAnimation freeze occurring, based on TextureAnimation working as it should during it's stationary moments. During the at_target() event, I added a SET_STATUS | PHYSICS FALSE to stop it instantly rather then let it ease in. Noticed that this forces the TextureAnimation to resume (unsure if it resumes or just restarts), it only seems to reduce the times of said issue happening. ?

[Further Edit: changing the PRIM_SPECULAR values yields the same results; resets the TextureAnimations. 

Have added a timer that fires up every 4s when in motion to toggle PRIM_SPECULAR changes]

 


Previously I assumed the TextureAnimation continued because of the object being stationary. But after reading the comment by Maestro, am not sure if it's due to it being still or if it's due to TextureAnimations being reset due to a full object update. Either case it seems have the same effects you mentioned in JIRA (right clicking or camming in and out). }

For documentation (if any), below is how to recreate, with a script using a listen() event to trigger the state switches (without contact with said object).

1. Rez a cube 
2. Insert the script below. [Note: I used a timer () in this recreation but using a at_target will replicate it as well] [Any texture can be used]
3. Set Object to be Physical and Phantom (optional)

4. There will be moments where the Texture animations just freezes up and the texture is displayed incorrectly (unlike any of the four cells)
(more specifically, the same appearance as having a non-animated texture with Horizontal scale: 0.25, Vertical scale: 0.25, Horizontal Offset: 0.375, Vertical Offset: 0.375.)
5. When said object's TextureAnimation freezes up, triggering SET_STATUS | PHYSICS, FALSE enables TextureAnimation to function  [Note: this works with changing the values of PRIM_SPECULAR as well]

vector oriPos; 

default
{
    state_entry()
    {
        llSetLinkPrimitiveParams (LINK_THIS, [PRIM_TEXTURE, ALL_SIDES, "c3187dbc-fbad-0544-f137-7568530451a9", <1.0, 1.0, 0>, ZERO_VECTOR, 0] );
        llSetTextureAnim( ANIM_ON | LOOP, ALL_SIDES, 2, 2, 0.0, 4.0, 5.0 );

        llListen (88, "", llGetOwner(), "");

        oriPos = llGetPos();
        llSetTimerEvent (4.0);
    }
    
    timer ()
    {
        llMoveToTarget ( 
        (<oriPos.x + llFrand(3.0), 
        oriPos.y + llFrand(3.0), 
        oriPos.z>), 4.0 );
        
        llSetTimerEvent (8.0);
    }
    
    listen (integer channel, string name, key id, string msg)
    {
        if (channel == 88 && msg == "on")
        {
            llSetStatus 
            (STATUS_PHYSICS , TRUE);
        }
        
        else if (channel == 88 && msg =="off")
        {
            llSetStatus 
            (STATUS_PHYSICS, FALSE);
        }
        
        else {}
    }
}



Would also like to add on:

The issue seem to occur although at random, but if you have various number of the objects (at varying TextureAnimation speeds even), the TextureAnimation freezing occurs at the same time (visually) as long as said objects are in motion. The TextureAnimation also resumes at the same time. 

To reproduce the following, 

1. Rez any number of cubes [Note: I rezzed three]
2. Insert the script from here and change the values of TextureAnimation speed -->
Script. [Note: I used a timer () in this recreation but using a at_target will replicate it as well] [Any texture can be used]
3. Set Object to be Physical and Phantom (optional)

4. There will be moments where the Texture animations just freezes up and the texture is displayed incorrectly (unlike any of the four cells) for all cubes at the same time as long as said objects are in motion.
(more specifically, the same appearance as having a non-animated texture with Horizontal scale: 0.25, Vertical scale: 0.25, Horizontal Offset: 0.375, Vertical Offset: 0.375.)

Edited by LucidiaErsatz
additional information

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...