Smooth animation cont.

Seems old threads die here pretty quickly so I'll start again...

I'm now at the point where I'm trying to get about 20 prims to all move in sync, but with no luck so far. I've tried using various techniques - timers, linked messages, private "Say" messages, simultaneous scripts etc. etc., but inevitably one or two prims will move at a different time to other others which completely ruins the effect I'm trying to create (of a locomotive piston+rod system).

Again, there's no real need for the server to care about any of this, but failing doing it all with textures (yuck) I'm not sure what alternatives there are.

I could also partially solve the problem if I could have a heirarchical linking system, where a child prim could have child prims of its own, but again, as far as I understand not possible. I suppose I could just delink parts of it so it wasn't all one object, but then communication between the objects becomes more difficult, and I'm not sure it would actually solve everything.

Even the best example I've seen of this sort of thing already done, at the Vernian Sea Lighthouse (http://slurl.com/secondlife/Karoastoff/226/46/67) suffers from this problem (this is done with multiple multi-link objects, so at least parts that are fixed together stay together), and this always runs at a single fixed speed, so perhaps there is no good solution.

I don't think it's really doable, unless you want to use 1 sculpty instead of a bunch of prims. With that, you'd just change the one sculpt map. Even that doesn't work that great (or at least the ones I've seen).

Does moving one prim in a link set cause a full object update? If so, maybe a JIRA suggestion for llSetLinkPositions ([int link, vector pos, ...]) would be a good idea. That doesn't solve your problem either but it'd make doing things like this easier in the future, if LL bought it..

edit: the best I've seen for moving prims is Todd Borst's stuff at http://slurl.com/secondlife/Schell/218/167/91. He sells his puppeteer scripts, which you might want to look at.

Puppeteer is pretty good but even it gets jerky if theres much going on. How about building your loco as a narrow gauge, with external frame and suspenstion. This would allow you to animate a texture on a singe prim per side that would represent the drivers, conrods, valve gear, and piston rods. Considering the frailties of sl, this might be your best bet.

Well the challenge was to create a working 3d model, and textures is just a really ugly solution, especially considering how big they'd have to be - and I would be creating them by screen-capturing out of the SL models, then importing them back in, which seems kinda silly.
I realised the multi-object solution is a no go of course, as the whole loco needs to move as one object.

I have some ideas about how to improve the coordination, e.g. using simultaneous infinite loops that just keep changing the position/rotation according to some external coordinated variable. But I don't want a script that's gonna generate huge lag either.

All I really need to do this is a way of setting the positions/rotations of multiple prims in one go, with no "updates" in between. I.e., a SetMultiLinkPrimitiveParams() function that takes a list with some sort of delimiter so you call it like

SetMultiLinkPrimitiveParams([2, PRIM_POSITION, newPos2, PRIM_ROTATION, newRot2, END_LIST, 3, PRIM_POSITION, newPos3, PRIM_ROATION, newRot3, END_LIST, 4, ...]);

...oh, and of course a GetLinkPrimitiveParams() function, which I still can't believe LSL could be missing.

I finally got something approaching smooth motion on a single prim by using 3 simultaneous scripts all running hard loops calling llSetPrimitiveParams(), with some code to ensure each starts at particular times (continually calling llGetTimeOfDay() until the msec part is the right value), and getting the pos/rot info from the root prim by using the object description (llSetObjectDesc at the root prim, and llGetObjectDetails(llGetLinkKey(1), [OBJECT_DESC]) in the prim scripts). I'm getting roughly 15fps, which should be adequate, and certainly would be if it was a fairly precise 15fps - which it's not of course.
Increasing it to 4 simultaneous scripts doesn't help appreciably, because the timing doesn't stay consistent.

But...this hasn't helped much at all in ensuring all the prims all move together. And further, it won't work well above a certain wheel speed - if I want the wheels to rotate at any more than about once per second it becomes a big mess (I guess I can live with this limitation).

Further I have about 27 prims to animate like this, and 81 simultaneous scripts running sounds like a recipe for trouble.

Also there's so much script copying & pasting that maintenance is a nightmare. There surely has to be a better way!

If you agree, then please vote for the outstanding JIRA bug to add the ability to adjust multiple prims simultaneously:

https://jira.secondlife.com/secure/ViewVoters!addVote.jspa?key=SVC-2105

Yes, that would be a very nice function to have but they're probably concerned about people making LSL copybots with it..


Maybe have the non-root prims be just a simple slave script and have the root prim contain all the smarts.. Read all the prim info from a notecard and send down the position/rotation steps to each child prim.

I think I've decided the only way I can keep the parts together now is to use a single prim with a texture, ideally a sculpt texture...I've looked around at various 3d modelling tools and I can't find anyway I can easily model the parts the way I can in SL (as cylinders and torii and boxes etc.) and convert it to a single sculpt. Does anybody know of such a tool? Looks like SnurbO'Matic is supposed to be able to do something like this, but I'm not quite willing to fork out 2500 $L just to see if it does what I want.

the problem lies in the fact that even though all parts might get effectively simultaneous calls to do something, their individual commands are queued by the server along with all other scripts on the sim. which might mean a noticeable delay in spots, especially with large numbers of prims. there really isn't any way to work around that

Is it also a problem that once the server moves the pieces, it has to send a message to every viewer looking that way to tell them that the piece moved? Those packets might not all arrive at the same time.

lee

I remember back when X-windows was being designed, people often complained that it assumed the network was faster than it really was. The X-windows designers used to say that by the time they were finished, networks would be fast enough. Maybe that is a way to look at a lot of SL issues like this one. Design it, build it, and maybe in a few years it will suddently start working...

I'd be surprised if it didn't contribute, even with some level of broadcasting changes

Yeah but in this case I don't *want* the server to send any messages about how the prims have moved unless it can send them all in one go. There should be no case where a client thinks that prim 1 has moved to its new position but that prim 2 has yet to move.
It's largely an API issue as I see it - either there needs to be a pair of functions to group updates (llBeginUpdatePrims()/llEndUpdatePrims()) or a function to update multiple arbitrary prims at once.

There's also the fact that there's no way to do client-side positional animation of non-physical prims, but I'd agree that's a case where better hardware/network speeds will eventually obviate the need for client-side animation.