Object to Object Rotation

I'm building a ferris wheel. The main portion of the wheel rotates using llTargetOmega. This works fine and the wheel rotates around the correct axis. My problem is the seats. Simply attaching a seat to the wheel causes the seats to invert, which while loads of fun , isn't exactly what I'm looking for.

I'm looking for suggestions on how I should accomplish the seats so that they remain level with the ground as they rotate around the circle. Is simply doing an llTargetOmega on the individual seats the best method? Any help is appreciated.

If you're going to actually expect people to ride the ferris wheel, you won't be able to use llTargetOmega because it's a client side rotation, meaning not everyone see's the ferris wheel in the same spot. You'll have to use the more advanced server-side rotations, which I have no clue how to use! LOL

Uh... llSetRot? It always seemed pretty straightforward to me.
If you want to set a rotation and you are clueless about quaternions and stuff you can use:
llSetRot(llEuler2Rot(<x,y,z> * DEG_TO_RAD));

Where x, y and z are the values you usually put in the edit box of an object...

I believe I have a solution to your problem.

llTargetOmega, as Styles said, is a client-side function. This means that the ferris wheel will not look the same on other people's screens. Also, when the ferris wheel sends a client-side update, it will snap back into the rotation it was at before llTargetOmega was called.

The way your problem can be solved is by using a kinematic (nonphysical) or kenetic (physical) rotation function to make your wheel rotate (I recommend kinematic). By doing this, you not only solve the client-side llTargetOmega problems, but you are able to use child rotation to make the seats align with the ground.

I have a few ideas on how to get it working, but I might need to do some experimenting on the actual thing.

==Chris

Put it another way it's non-trivial

The problem is that we dont have axes at this time, so you basically eithr have to use non-physical - which is jerky - or to fudge the system some how.

One possiblity would be to make the cars that people ride vehicles and use something like llMoveToTarget or llSetForce to push them around. You can lock the rotation so they dont actually rotate, and stay horizontal.

The problem is that it'd be very hard to get them to move in an exact circle, so one possibility might be to modify what youre trying to make very slightly so that it fits in with what is easily possible.

For example, you could have people moving around in little cars and stuff, following a preset course, but no longer intending to be a ferris wheel, more like a rollercoaster, or little microplanes flying through a magical worldscape.

Or you can reclassify having the cars turning upside down as a feature.

Azelda

I want to use rotation to get a ride going.. it has a sphere on the top that I want to rotate when you touch it and stop when you touch it again, and when you stop it, the stuff hinged to it will keep going.

I used llSetRot for this but it doesn't work with the physics.. the whole ride rotates and stops at the set rotation.

I'm going to go look around some more, if you have any ideas get back to me.

EDIT: FYI: The sphere on the top is non-physical (so it floats in mid-air) and the hinge is point-to-point.

EDIT 2: I got the desired effect.. maybe I was doing something wrong before. I used llSetPos and llSetRot.

EDIT 3: Okay so I didn't get llSetRot to work properly, but I'm not using it on that particular project anymore.

SO.. new project, new question..

Eggy said to use llSetRot(llEuler2Rot(<x,y,z> * DEG_TO_RAD));

...now, if I have a current rotation in a rotation type, how can I get it to work.. I want to do the same thing but instead of <x,y,z> use <x,y,z,s> or whatever the rotation format is. Is there a way I can convert a rotation to a vector? Because I don't need the s for what I'm doing.

EDIT 1 MILLION: Got it figured out! It's in a code snipit on the wiki.

Sorry to jump into this thread, but I'm working on something where the application of llSetRot is also relevant (and similar to this), and I had been toying with llTargetOmega until I realized it was a client-side function (from this thread).

I'm trying to rotate helicopter blades. I have my rotations working just fine. The problem is, the speed of it. It doesn't look realistic.

I have a timer event set up to repeat the llSetRot 's. But the fastest I can get it is like 0.1 or 0.2. Any lower (ie, 0.001) doesn't make any difference in the speed.

Is there any way around this? You can imagine helicopter blades and how fast they'd have to move to look realistic.

I prefer prims over textures. And would really like to avoid just using a texture rotation for this (besides, I think that's client-side too, isn't it?)

Anyone have an idea of how I can do this?

Thanks,
Omen

I think a rotating texture animation would be the best thing to use for this purpose. A call to llSetRot delays the script 0.2 seconds, that's why making your timer event interval less doesn't affect the rotation.

I wouldn't recommend llSetRot since, later on, you'll eventually need to link the blades to the plane. There are ways to rotate child objects, but they tend to be a bit erratic.

Even if the texture animation is client-side, propellor blades dont normally interact with the world. llTargetOmega is more noticible, since it actually moves an object.
==Chris

Thanks for the reply Christopher,

Well that explains it then. No set rot for this project. Or at least for this part of the heli.

Target Omega, when I was experimenting with it, seemed to work on and off. By that...I mean the blades would only rotate after a script compile. Rezzing the heli wouldn't start the rotors spinning (with commands in both state_entry, on_rez, and anything else I could think of for inits - as well as using a touch even to try and start the rotation). The only way they'd begin spinning is if I'd go into the script and re-save/compile. Then they'd start up. I don't understand why...

I guess my only option left is the texture based rotation.

Owell.

Thanks again,
Omen

I am having trouble finding such a thing, can you give me a hint?

Basically I want to rotate an object on a local axes but am having little luck of figuring out a method using the angle. I have made it work by calculating the sin and cos of the angle (in one plane) and putting these values in the vector to llTargetOmega() but this is a terrible hack.

I also figured out:
rotation rot;
vector rotVec;
vector objRotAxes = <0, 0, 1>; // object z axes
float objRotDeg = 45; // object rotatoion about z axes
vector rotAbout = <1, 0, 0>; // rotation x axes

rot = llAxisAngle2Rot(objRotAxes, objRotDeg * DEG_TO_RAD);
rotVec = rotAbout * rot;
llTargetOmega(rotVec, -0.5, 1.0);

But this is about the global coordinates so if the object os positioned with a different orientation the rotation of the object will be wrong. So the script would have to be changed. Somehow I need to work in the local orientation. Help.

OK, what I wanted to do was rotate a turkey in a BBQ spit that was not aligned with a global axes.

Bran

and while we are at it, how would you script a kite to always face the person holding the string?

I think your best bet to create a ferris wheel would be to use a cylinder for each side of the wheel and create bars that connect between the wheels to hinge the carts from. then set the basic rotation script that everyone gets when they first join SL to rotate the wheels. the hinged carts should remain parrallel to the ground if I am not mistaken. If I am wrong, the carts would just continue to flip over at the top making for a really fun ride. Good luck.

"There is no such thing as a stupid question. Just a lot of inquisitive idiots."

OSMP supports hierarchically linked rotations, ie you can build a wheel and rotate it, then have chairs linked to it rotating in the opposite direction at the same speed, so that the net result is something rather like what you are looking for.

Azelda

Here's an idea...

Take two very short, 10x10 cylinders and rotate them on their sides, 90 degrees. Place thin cylinders between these. Now, make your gondola. On the top of the gondola add 1 or two torii, rotated so their holes can go around the support bars you created before. Make sure the torii are big enough to completely fit around the support bar without intersecting it. Make the gondola physical. llSetRot() the wheel (linked to the support bars, but NOT the gondolas). I think it's along the same lines as what Jason Foo was talking about, but the gondolas need no kinetics, they'll just orient themselves down automatically from the force of gravity. The only drawback I can think of is if you got the wheel going REALLY fast the client may not update quick enough and the gondolas could go flying -- which, come to think of it, sounds like a pretty cool ride, as long as they would llDie() when x distance away from the wheel!

Whats OSMP?