how many calls is too many??

Whats up yal... Hope everybody who celebrates/ is celebrating a holiday is enjoying it

Got a question about llSetPos() and llSetRot() ... How llSetPos() and llSetRot calls per second would you say is too many? and where would be a good place to test this w/o catching grief if i accidentally lag the sim. The idea im working on will call them about 80+ times total a second spread over multiple prims moving them relatively short distances.

TIA
O

If you don't mind, could you tell us a little about what you're trying to accomplish? That way, someone might first be able to suggest an alternative, more efficient solution (if one exists) for accomplishing the goal you have in mind.

Your script will never run at 80 llSetPos() & llSetRot() refreshes per second. Your script could call it, but the server just want let it run that fast.

Ok, I guess I should never say never... but, it's fairly taxing to get 10 refreshes per second, and 80 - over multiple prims/object - I just don't think is possible yet.

Let's see... A dragon has 42 moving child prims, these change position and rotation every 0.375 second, which give us a total of 112 such refreshes per second.

I can easily have four dragons animated on screen at the same time, so 448 refreshes per second is still fine. I guess the maximum you can have is really limited by the sim's performance and could go as high as a few thousand.

Thanks for all the info yal .. I have been simmering a couple different animation module ideas in my head for a couple months.. My main goal is to make it easier to make multiple animations that can be applied to multiprim objects by streaming out frame data via llLinkedMessage, llShout, llSay.. or whatever way I figure out... b/c its looking pretty process intensive with the end anywhere b/t 5-100prims at X frames a second I am trying to figure out some limits to work within.

Yeah. My reply referred to 80 refreshes per script.

In regards to your question concerning where to test something like this, try the sandbox sims, thats what theyre there for.

A call to llSetPos sends a partial object update to the object - the server only sends the new position data to the client. (They show up as blue cones when Debug>Show Updates is on.) In Show Updates mode, an object calling llMoveToTarget emits many of these blue cones throughout the duration of its movement, so I dont think calling llSetPos many times poses much of problem.

You are going to run into a barrier when attempting to call this function 80 times a second from one script, however. Calling llSetPos causes the simulator virtual machine (script runner) to stop the execution of the script for 0.2 seconds after the movement is complete, making the maximum number of calls per second 5. There is a way to workaround this problem, but its tedious to manage. Instead of having one 'master' script call the function, deligate calling the function to several 'slave' scripts that activate when they receive a link_message event triggered by the master. I personally hate using something like this because it's hard to setup and update, but to each his own

Good luck!
==Chris

Me and Christopher have had an object animation system like the one you describe for ages.
If your object is prim-heavy and it needs the prims to move in sync, it's definitely not possible to get a smooth animation unless you have a completely empty simulator, and it works best if you dont update it 80 times per second, but rather try to work with the builtin interpolation SL gives you. But LL is working on giving us the tools to make animated objects a reality... which at this rate will take about a year

I was shooting for more 5-10frames per second(not too wishful i hope) .. not 80 frames a second..lol Slave scripts wouldnt be a trouble.. i have thought about implementing them in a couple other cases too and with internal variable to ID each one.. automating expansion as needed shouldnt be that hard.

but also I was thinking separate multiprim objects.. 17or so(arms, legs, head, wings and body..etc..) listeners parsing strings of data to compared to 30+ separate prims via llLinkedMessage() with each parsing its own data out of the frame. Or Possiblely initializing each prim with its frame sequence b4 the animation starts and having the controller "ping" the start of each frame?




It MUST be done sooner!!..lets see a group of "players" vs. LL ... who will be the 1st (LL's will probably be the final product) to release the animation tools that will bring SL's multiprim community to LIFE!

FWIW, I've got a prototype set of animated wings that will move 32 independent wing elements (with llSetLocalRot()) with a reasonable -- not perfect, but reasonable -- amount of synchronization, even in a populated sandbox sim. It's not sync'ed to a real-time clock, though, and performance does indeed hinge on local lag characteristics. IM me in-world if you want a demo.

Jess.