Smooth animation of objects?

Hi,

It seems that the frame-rate when trying to animate objects via scripting is very low - probably 10fps at best. Because of this it seems that there's no way to make non-physical objects move smoothly. I want to be able to calculate the path of my object (it will follow a vertical spiral), so I don't even see how I can really use a physical object to do it. It seems odd that we have llTargetOmega to smoothly rotate non-physical objects, but we can't use llMoveToTarget in a similar fashion. Just calling llSetPos in a hard-loop gives very jerky movement, and using a timer event is worse.
Is this a known limitation of SL scripting?

Thanks

Dylan

Yep there is an enforced 0.2 second delay for every call of llSetPos.

The reason llTargetOmega is so smooth is because it's client-side only. Contrast that with other functions like llMoveToTarget, which are both server and client side. One of the first things I do when I look at timing in a script is go to the wiki's and check to see if there is a sleep time on the function. If there is, then I take that into consideration during development.

There are several so-so solutions to this problem. Search for public scripts named nonphys or multimove. Those are large complicated scripts with many other goals besides increasing the frame rate, have fun reading them! The basic idea is this: You stick 4 copies of a simple slave script in your object that each call llSetPos 0.05 seconds apart. Each script is delayed by 0.2 seconds, but the others are allowed to keep running. This example produces 4X the frame rate, at an unclear cost of bogging down the server or your scripts getting out of sync.
I've been experimenting with using llMessageLinked to keep them in sync by starting the slave scripts over every 0.2 seconds. In my main script instead of calling llSetPos, I call this function babystep():

babystep(vector deltas)
{
float now=(float)llGetSubString(llGetTimestamp(),-10,-2);
llMessageLinked(LINK_THIS, 0, (string)(deltas/4.0)+(string)now,"";
}
Where deltas is the vector I would have added to llGetPos and given to llSetPos.

Then I have 4 copies of the following script running in the inventory with names move0 move1 move2 and move3 (the last numeral of the name is important):

float seconds(float since) //seconds since a starting time, decimal part accurate to miliseconds
{
float now=(float)llGetSubString(llGetTimestamp(),-10,-2);
now=now-since;
if (now<0) now=now+1; //must use within 60 seconds of since
return(now);
}
default
{
link_message(integer part, integer steps, string msg, key id)
{
list parts=llParseString2List(msg,[" ","<",">"],[]);
vector step=<llList2Float(parts,0),llList2Float(parts,1),llList2Float(parts,2)>;
float startime=llList2Float(parts,3);
//use script name to get all the scripts out of phase
float sleeptime= (float)(llGetSubString(llGetScriptName(), -1, -1))*0.05;
sleeptime -= seconds(startime);
if (sleeptime>0.0)
llSleep(sleeptime);
llSetPos(step + llGetPos());
} //link_message
} //default


I've seen this work well, but I have not tried it in laggy regions. It seems stupid to have to do all this conversion of vectors into strings and back, send and receive messages just do get a decent frame rate. It would be much more efficient to provide a way to do this in the server. The Lindens will tell you to use the vehicle routines, but those have their own limitations.

Nonphy move is terribly laggy. The reason LSL imposes a delay after calling certain functions is to keep us from calling them frequently, since it would cause a heavy load on server or client. We should think three times before resorting to tricks to circumvent them.

For things that are rarely used, or that only move occasionally, no big deal.

For things that are intended to be prevalent and/or in continuous use, it's a bad idea.

Yeah I read about the multiple scripts technique after doing a bit more searching.
I'll probably play around it.
I actually don't need the animation to be done on the server side - it's in a small area and won't affect collisions etc. But there doesn't seem to be any way to animate actual prims on the client side only.
What are the "vehicle routines"?

FWIW, I have the multiple simultaneous scripts thing working reasonably well - but is there a way of avoiding duplicating the code between them? That is, can I write a function in one script and call it from another? I guess I can do all the calculations in the root and pass the results to the various scripts via as messages on private channels, but I'm thinking that isn't likely to be very efficient. Is there any other way to pass information around between scripts? Could I use (as a kludgy last resort), the root description field, e.g.?

FWIW, what I'm now trying to do is animate the pistons on a locomotive. I have all the logic worked out, but if you try to do it all from one script it takes about 2 seconds just to move all the pieces, and of course they don't move simultaneously. Looks like each moving prim is going to need at least two scripts with separate timers, where either they all duplicate the calculations (and hence I have to duplicate the scripting code), or they have a way of grabbing the calculated values from the root.

There are routines specifically designed to help you write vehicles. See http://wiki.secondlife.com/wiki/Linden_Vehicle_Tutorial
These animate physical objects to make them move smoothly. Probably won't help you now that I see what you want.
Have you considered animating your pistons as flat texture maps? llSetTextureAnim with a cleverly designed texture map in PING_PONG mode could do a piston. Or a series of frames embedded in one texture map. Of course, the result is flat and will look strange from some angles...

The only way for different scripts to share information is by communicating, using linked messages, chat (not advised), or passing the information using some shared resource. Unfortunately, prim description only works for scripts in the same prim. Parsing the ASCII and converting to float may take more time than simply duplicating the calculations. Most of the other places to pass info has the same problem as doing the physics: they cause a delay.

I often code up the critical part of two different implementations, put each in a loop and run it 100 or 1000 times and time them. This wouldn't work well for the communcations part, just the parsing vs. computing.

You may want to find someone willing to give you estate management rights so you can see how much script time your object uses. Avoid sitting on it when you do, or remove all scripted attachments, because otherwise they get counted for the object you're sitting on.

I think for your application the best thing to do would be to create a set of sculpted prims for each set of piston states you want to represent, with ALL the pistons in the same prim, and reload the sculpt texture in a loop.

Even better would be for SL to implement a sculpt version of "llSetTextureAnim".

...that's the path I'm trying to take, but I'm struggling to find a tool that makes it easy to create such a sculpted texture...I started a thread in the Building Tips forum:

/8/e6/303126/1.html#post2294203


(BTW, why doesn't "Automatically parse links in text work" for me? I've seen at least one poster be able to put links in threads I've started, but it's not working for me, or some others like Kayaker Magic above - it just puts ... around the link)

I can't figure that one out either. I always end up with the tags too. I'll love to know how to do it right.

Dunno, it seems some posters can create URLs and others can't...at first I thought it was to do with the extension at the end of the URL (all the ones I saw that worked ended in .jpg or .png) but not even those work for me.

I think there's a trick you can use with [img]tags but I don't know it.

Actually that's exactly it - auto parse links only works when the text is between , e.g.

They turned off a number of tag features in the forum due to a security threat, nearly two years ago now (telling us they'd fix it ... yeah, we're waiting ...)

Many folks use a plugin for Firefox that makes them work anyway, but if you simply use [img]tags, it won't work for them. I believe that if the URL ends with a question mark (or has a question mark in the arguments section), that it DOES work with this plugin.