Going round and round and up and down?

I've been asked to make something that involves having two objects both orbiting round a central point, like two planets round the sun. I can do that, because I've read the example in the wiki of rotating objects round a relative point and also /54/92/263006/1.html

However, I also need to make them go up and down at random intervals. Imagine the movement of an old-fashioned fairground horse, only firing randomly.

And, while I can make things go up and down on their own z axis, as well as obit round a central point, I have no idea how to do both at once.

Can anyone advise me? Please... I'm planning on using physical movement, since that's going to be easier to control.

Can you do llTargetOmega for the rotation of the two objects combined with llMoveToTarget to have them go up and down?

edit: ie, does it have to be all one object?

No, I hadn't planned on making it all one object. I'd envisaged it as single objects.. because the moving parts only need to be one prim each .. describing a circle round a point in space and now and again moving up and down while they continued their orbit round the central point.

I understand how to make them circle, using equations like the ones here /54/47/173709/1.html#post1451564 , for example, and I understand how to make them move up and down, of course, but what I don't understand is how to combine the two.

Unless.. do I just start increasing or decreasing the value of z for a bit, on a counter, when I want them to move up and down, while continuing to change x and y as as before? It can't be that simple, can it? I must check when get in world tomorrow.

Sure.. You can do that..

I was thinking of using more than one prim per object, though. Take this ASCII art masterpiece of a 2-prim object:

Say the O is your visible object and the ----'s is a cube, resized to be sorta shaped like a ruler. Pathcut the cube and link your visible object onto the non-cut end. Slap a script into the ruler with this in state_entry:

llTargetOmega(<0.0,0.0,1.0>, TWO_PI, 1.0);

That should make the entire object spin around the .z axis once every second. You can mess around with the first 1.0 and/or TWO_PI to change the rotation rate. If those two multiplied together come out to TWO_PI, it rotates once every second. If those two multiplied came out to PI, it'd be once every 2 seconds..

The deal with the pathcut is that the rotation occurs around the center of the root prim. Cutting the cube in 1/2 just makes it easier to see where that is. Just make the cube longer/shorter to get to the right sized orbit.

If that works well, add in some random llMoveToTarget's to change .z at random rates and Bob's your uncle..

Wow.. thank you!

One question, though.. I was always told to try not to call llTargetOmega in physical objects. Or, since I'll have to keep on frequently recalculating my target vector anyway, does it not make a great deal of difference?

/me doesn't know why you wouldn't call llTargetOmega on a physical object.

The wiki seems to be okay with it, though it sounds like there's a bit more sim load if physics is on. As long as the sim isn't being pushed really hard already and you don't have a ton of these things in the region, I wouldn't worry too much about that.


How often are we talking about? If you're talking about changing the height more than, say, once a second, you're close to just being able to use llSetPos instead of physical/target - moving that quickly, people may not notice the difference.

Also, if you're just moving up/down, make sure to put one of these in, right before you enable physics:

llSetStatus (STATUS_ROTATE_X | STATUS_ROTATE_Y, FALSE);

That'll keep it from going all wobbley.

edit: also, when I mess around with rotating things, I usually find I can save myself a lot of aggravation by changing the ruler mode in the edit window to be Local. Make sure that the object's blue arrow (local z axis) is pointing up or it won't behave like you expect.

Thanks, Meade -- sorry, I didn't make myself at all clear.

What I meant was, if I use llMoveToTarget to rotate the object, rather than llTargetOmega, I'll have to keep on recalculating my new x and y values anyway to keep it moving round in a circle, so there's probably no great advantage to doing it that way rather than using llTargetOmega in a physical object.

Yep!

edit: and performance-wise, I think using llTargetOmega and llMoveToTarget is a win over using llMoveToTarget for all of it. In general, I think the less often your script runs, the better.

OK - bear in mind this is from a pretty clueless scripter

I was recently fiddling along these lines with the objective of creating some floating lighting effects that would circle a dance floor.

What I have so far is the light object linked to a root prim. The two prims don't need to actually be connected but the maximum radius of rotation is determined by the link limit.

Putting a rotation script in the root prim has the linked object rotate about the axis of the root prim so the child object sweeps a circle.

I would imagine adding a random fire script that would cycle the root prim through a Z co-ordinate offset would make the rotating prim appear to rise and fall also. This I have not done, but it has given me ideas

Build two (or more) of these and have the root prims share the same start location and Bob's some relation. Add a random drift in rotational speeds (assuming this is a- possible and 2- doesn't glitch the viewer) and you'd have all sorts of mad objects chasing each other around and jumping for joy...

... or not. I did say I didn't have much of a clue

Rime

I imagine that you could get the right effect by simply making three linked objects that rotate around a common point. Make each object out of three prims ... two visible ones and an invisible one halfway between them that you set as the root prim. Put the invisible root prims of all three linksets in the same place, but tilt the linksets so that their vertical axes are all different. When you get all three rotating around their root prims, the visible prims should appear to bob up and down as they rotate. Especially if they rotate at different speeds, it should be a fairly dizzy-looking arrangement.

Just to illustrate where I was going with my suggestion...

http://www.flickr.com/photos/rimewirsing/4046889927/

... this is a rough clip from my cr*p work graphics.

Five prims in a link set. Root prim rotates in the x-y plane and the 'light' prims rotate on their own axis to achieve the swirling motion effect.

It's a work in progress

Rime