# Thread: Moving a part/object at an odd angle

1. ## Moving a part/object at an odd angle

I have a tripod that I am rigging and I want to be able to move the leg sections up and down. In the past I have used bones and local coordinates to maintain the respective angle.

There are a few suggestions like using bones and using nulls (which I have used in the past as well). But I am curious if there are better (easier/faster) techniques that might have missed (nodes perhaps?).

2. For me, the Local Coordinates in Layout seem really hard to use, but I'm not expert. Using Move Pivot Point and Rotate Pivot Point don't really seem to give me the ability to position and / or rotate an object (or layer) using a coordinate system local to that Object. Very specifically, Rotate Pivot Point doesn't seem to change the orientation of the X,Y and Z axes for motion. Maybe I'm missing something!

I don't know if it'll help in your situation, but here's an LScript which sets up local coordinates for an Object (or Layer or an Object) based upon a Skelegon create in Modeler:

When you have an oddly positioned / oriented part of an object, put it in a separate Layer, and create a Skelegon pointing down the desired Z axis and rotated in Bank if necessary to define the origin and orientation you want for that part in Layout. Here's a video showing the setup:

To create the Skelegon, I used the method of selecting two points (IN ORDER!) along my desired Z axis, in this case the length of the box. CTRL-p creates a 2-point curve, and the Convert Skelegons converts it into a skelegon. I then deleted the 2-point curve to clean up the layer.

The LScript creates a Bone from the Skelegon you drew / created in Modeler, then creates a Null (called <name>_LocalCoordNull) at the same orientation as the Bone, parents the mesh Object to the Null, and then sets the Bone's rotation to (0,0,0).

The result is that movement and rotation of the Object using either Numeric input or mouse input will be in the Null's coordinate system. For the tripod leg, if the Skelegon is oriented along the leg, you'd just move the leg portions in Z.

Good luck!
mTp

3. Is this not what you're trying to do? (move the nulls not the bones)

4. Yes, with a bone hierarchy it works great (as always!). This was my setup for that scenario, moving the Goal nulls to extend / spread the tripod legs:

MOV file: Tripod_IK_ThreeBones_ClonedTwoMoreLegHierarchies.MOV

In the sample scene, I left all three Goal Nulls with the same motion, but they could certainly be different.

I posted the LScript as a potentially easier way of setting up Local Coordinates for a single object / layer by just drawing a Skelegon in Modeler and running the LScript. It certainly won't replace a well thought-out rig!

mTp

5. Originally Posted by MonroePoteet
Very specifically, Rotate Pivot Point doesn't seem to change the orientation of the X,Y and Z axes for motion. Maybe I'm missing something!
Can you describe an easy replication of the problem?

If a reproducible bug, it needs to be reported.

6. Originally Posted by RebelHill
Is this not what you're trying to do? (move the nulls not the bones)
Damn, you make stuff look too easy! Thanks! Additionally, this set up will help eliminate the ugly null hierarchy that I set up to handle the rotation of the legs to the amount.

7. Originally Posted by MonroePoteet
Yes, with a bone hierarchy it works great (as always!). This was my setup for that scenario, moving the Goal nulls to extend / spread the tripod legs:

MOV file: Tripod_IK_ThreeBones_ClonedTwoMoreLegHierarchies.MOV

In the sample scene, I left all three Goal Nulls with the same motion, but they could certainly be different.

I posted the LScript as a potentially easier way of setting up Local Coordinates for a single object / layer by just drawing a Skelegon in Modeler and running the LScript. It certainly won't replace a well thought-out rig!

mTp
mTp: Thanks as well! Similar to RH. Both are a great help.

8. Originally Posted by jwiede
Can you describe an easy replication of the problem?

If a reproducible bug, it needs to be reported.
Well, I think it's clearly just my misunderstanding, but here you go:

2) Use Modify=>Coord to set to Local Coordinate System
3) Use Modify=>Rotate Pivot and type 45 degrees into the Pitch field
4) Press "t" to go to Move Mode, then use the slider in the Z axis to move it down the Z axis

MOV File: RotatePivot_DoesntChangeLocalAxes.mov

With a Local Coordinate System and the Pivot Point rotated 45 degrees in Pitch, I'd expect the object to NOT move straight down the Z axis as it does. I'd expect the local coordinate system to be rotated 45 degrees in Pitch relative to the World coordinate system, causing the object to move in both World Z and Y when moving down the Z local coordinate axis.

Since it works the same in LW11.6.3, LW2015.3, LW2018.0.7 and LW2019.0.3, it's clearly just my misundestanding, but for me it certainly strains the usefulness of a LOCAL coordinate system, which I'd expect to be based upon the position and orientation of the Object's pivot point.

mTp

9. Originally Posted by MonroePoteet
Since it works the same in LW11.6.3, LW2015.3, LW2018.0.7 and LW2019.0.3, it's clearly just my misundestanding, but for me it certainly strains the usefulness of a LOCAL coordinate system, which I'd expect to be based upon the position and orientation of the Object's pivot point.
Yeah, I see. Nope.

Pivot rotation is done within the local object space. Rotating the local space itself of an object is, essentially, identical to rotating the object itself, and that occurs within the parent space (or world if no parent).

10. OK, thanks for the explanation.

I wonder if there would be any negative impact if LWDG implemented what I describe, since it would only consist of adding one transformation (the Pivot Point Rotation matrix) to the Translation pipeline when the Coordinate System was set to Local.

From what I can tell, at this point there's really no difference between Parent and Local coordinate systems in terms of translation, so maybe nobody would notice the change except users who want a real Local coordinate system implementation based upon position and rotation of the Pivot Point.

And, it would implement a true Local coordinate system which I think would be really handy!

Of course, I could be *completely* wrong!

mTp

11. There is a difference... take something, parent it to something, and set its rotation to 0,0,0... parent and local handles match... now rotate the child item, local and parent handles now point in different directions.

If you rotate the local space, you rotate the object, the 2 are indistinguishable. Easiest way to see this is modeller. The "grid" in modeller IS the local space/co-ord system of the object. It should be obvious that any attempt to rotate the grid "beneath" the object is identical to rotating the object itself within the space. Making any such change would risk breaking ALL scenes with hierarchies from any version prior to the change.

What would be better, and serve what you want, would be to add a "custom" co-ordinate system, where you could set (as in rotate) the orientation of the gizmo/handles.

12. Again, OK, thanks for the explanation.

Thinking about it, I agree that changing the behavior of Local Coordinate Systems would be very risky for legacy scenes and the wrong solution. I think it's a great idea to add a "Custom Coordinate System" whose origin and orientation is based upon the Pivot Point's location and rotation without breaking legacy scenes.

Currently, the Local Coordinate System is only implemented for the Object's rotation, not it's translation, which to me is inconsistent and confusing:

The Custom Coordinate System would be an excellent and I think valuable addition.

mTp

13. ahhhh.... you're talking about the breakout box... Yeah, because that's the RECORDED value you're entering there... which is ALWAYS in parent space, and MUST be so. Think about it. You key an item using parent co-ords, then switch to local, and the values change to that system. What is the "actual" recorded position of the thing? Does the previous key change intot he new system? Think of all the possibilities for screw ups. This ofc is not to mention that local cor-ords are local to the object itself... move the object and its local co-ords go with it... thus, a given object is ALWAYS at 0,0,0 in its own reference frame and can be nowhere else. This is the very meaning of the term LOCAL. For instance in the local co-ords of the earth, LA is always X miles south east(ish) of Tokyo, and this doesnt change no matter where in the solar system or galaxy the earth is.

The co-ord system affects ONLY the manipulators... NEVER the recorded values.

Make sure to see...

and

14. OK, I'll take a look at the videos when I get a chance. And thanks for your remarkable efforts in creating the library of videos to help us all understand LW better!

I believe there would be great value in a Pivot Point based coordinate system which could be set up per Layer in Modeler, perhaps called "Pivot Relative" or "Self-relative" coordinate system, or your proposed "Custom Coordinate System". This would effectively make the Layer's Pivot Point the origin and the Pivot Rotation would define the X,Y and Z axes in that self-relative space. The Pivot Point would be the Layer's "parent" without having to create a Null in Layout its place (as I did in the previously posted LScript).

The examples given in the thread referenced in the original post point out the value of a self-relative coordinate system, and I've had the same issues. For example, modeling an aircraft landing gear simulation in which there are many inter-related moving parts with each part having an independent pivot point and X, Y, Z orientation (defining heading, bank, and pitch). It would be extremely valuable to be able to model this sort of hierarchy with each piece in place relative to each other and the airframe, and then being able to SET the pivot point location and orientation for each individual piece in place.

mTp

15. I think you're still not getting the idea of what local space really is. It MUST, by definition, move (rotate, whatever) with an item.

Seriouly, take any object you like (in the real world) and move it relative only to itself... oh look, you cant, because any co-ordinate system which is based upon the object itself must go with that object. if it doesnt, if this "grid" is somehow "left behind"... then it's a higher level space external to the object.

You're imagining something which cannot exist... physically, mathematically, no way, no how.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•