How to link prims with a parent with a desired orientation?

How do I combine prims into a set that inherits the local axis AND current rotation of the parent prim? Or, rather, how do I turn a link set which "points" in the positive z-direction into a vehicle which moves "forward"?

I'm trying to make a vehicle, for which I apparently need a linked set of prims which "point" in the positive x-direction. The main body of the vehicle, however, is a cylinder, which points in the positive z-direction. The vehicle also include two spheres, which also need to be oriented such that their z-axis point forward (in the desired direction of vehicle motion) in order for their dimples to be properly aligned.

Thus, I need (apparently), to create another prim whose local positive x-axis points in the direction I want the vehicle to go, and link the prims together with this dummy prim as the parent. When I does this, the orientation of the link set is (often enough) that of the dummy prim. However, the rotation of the link set is (x: 0, y: 90, z: 180), meaning that when the vehicle script tries to go in the positive x-direction, it tries to rotate the vehicle to have no rotation.

Also, what determines the orientation of a prims local coordinates when the prim is created? Sometimes they seem to line up with the world coordinates, but just as often they point in random directions.

Also, why are prims created with a y-rotation of 90 degrees?

Also, is there any way to rotate a prim relative to its local coordinate axes?

The more rounded prims (spheres, touruses, tubes, and rings) are rotated 90 degrees on Y by default. The simpler ones (cubes and cylinders) are not. If you want your vehicle to point in the positive X direction, make the parent prim a box with no rotation.

To answer your last question, to rotate a prim on its local axis, select "Local" from the Ruler Mode pull down menu on the editor.

As I said in my original post, I tried this. The resulting link set has the axes/orientation I want from the box (i.e. the local positive x axis points forward), but the ROTATION of the link set is not 0, 0, 0 (which was the rotation of the box), but (0, 90, 180). Thus, when my vehicle script tries the rotation to 0, 0, 0, I end up moving in the wrong direction. How can I force the rotation of a link set to be that of the parent prim?



Obviously, but this rotates the axes with the object. Is there any way to rotate a prim RELATIVE to its local axes, that is, so that a cylinder will point along its local x-axis for example, instead of its local z-axis?

Uh, no you didn't. You never said you tried making the parent a simple box, only that it was "a prim" with no rotation, which could mean anything. The reason I said make it a box is because people have different definitions of what "no ration" means for different prims. For example, some people considier no rotation on a torus to mean its donut hole is faces up & down default (0,90,0). For others it means the hole goes east & west (0,0,0). Making at a cube simplifies the matter. If you've already done that, great, but don't say you've specified something when you haven't or it's not going to be easy to help you.


I'm not following you. First you say the object is rotated to (0,0,0), then you say it's not. In your first sentance, you said the local axes are in accordance with the global ones, meaning you see no difference when you switch from local to global ruler mode. If that's the case, then by definition, the object is rotated to (0,0,0). Where are you getting this figure of (0,90,180) at the same time as the figure of (0,0,0)?

It sounds like what's going on is you don't have the main vehicle script in the parent prim, but in one of the child prims. Either that or you're using a bad script. Those are the only things I can think of that would cause your vehicle not to move in the right direction.


Ah, what your asking is can you change which side of an object is considered the top, bottom, front, back, etc., or to put it more simply, can the pivot point of a prim be rotated independantly from the prim itself. The answer is no. Pivots in SL are fixed. The "top" is always side zero, which is the side on positive Z on the local axis. The "front", positive X on the local axis, varies from prim to prim. For a cube it is side 2.

Apologies. I had tried it with a sphere as the parent prim, and at your suggestion I tried again with a box.



I know it doesn't make sense, but that's what happened. Let me try to explain in more detail.

My "ship-proper" consists of three prims (with the same local axes); its main body is a cylinder, so the ship points along the local z-axis, with the top facing the positive x direction. I created a box to use as the parent prim of the ship. It had no rotation (i.e. its local axes matched the global ones and the rotations given in the "Object" tab of the more details of the edit window were 0, 0, 0). The ship itself had a rotation of (0, 90, 180), which was necessary to point it in the global positive x direction (with top facing positive z) for linking with the box.

Now, when I link it with the box, something strange happened. None of the prims moved or rotated (which is normal). The box was the last selected prim, and became the parent. The local axes of the combined link set matched the global axes (that is, I saw no difference when switching between the two views). However, the rotation given in the "Object" tab of the detailed Edit window listed the rotation of the combined link set as (0, 90, 180). I know this doesn't make any sense, but that's what happened. It appears that somehow the link set was given the orientation (axes) of the parent prim, but the rotation of the others. If I then set the rotations in the text fields to (0, 0, 0), the local axes of the link set are no longer aligned with the global axes, and my ship "points" in the wrong direction.

Is this a bug? Are link sets supposed to inherit the axes and the rotation of the parent prim? Is this documented anywhere (all I found was that they take on the local axes of the parent, I haven't managed to find anything about the rotation) or is it implied? Is there any way to specify the resulting rotation of a link set to try to get around what seems to be a bug?



The script is indeed in the parent prim and seems to be working properly. At least, it worked properly for another vehicle (which had the proper orientation), and it worked properly when I modified it to work with the original 3-prim ship and move in the positive z-direction instead of the positive x. I think it more likely that the strange behavior described above caused the problem, not the script.