PDA

View Full Version : Moving a part/object at an odd angle



wesleycorgi
04-04-2019, 12:48 PM
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.

I found this thread: https://forums.newtek.com/showthread.php?140794-Lightwave-sucks-when-you-need-to-move-objects-at-odd-angles

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?).

MonroePoteet
04-06-2019, 01:27 PM
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:


144679

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:


MOV File: 144680

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

RebelHill
04-06-2019, 01:41 PM
Is this not what you're trying to do? (move the nulls not the bones)

MonroePoteet
04-06-2019, 02:19 PM
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: 144682

144684

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

jwiede
04-06-2019, 03:30 PM
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.

wesleycorgi
04-06-2019, 04:48 PM
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.

wesleycorgi
04-06-2019, 04:54 PM
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: 144682

144684

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.

MonroePoteet
04-06-2019, 05:35 PM
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:

1) Load an object
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: 144688

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

RebelHill
04-07-2019, 07:30 AM
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).

MonroePoteet
04-07-2019, 08:40 AM
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

RebelHill
04-07-2019, 09:02 AM
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.

MonroePoteet
04-07-2019, 01:12 PM
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:

144691 144692

144693 144694

144695

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

mTp

RebelHill
04-07-2019, 01:19 PM
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...

https://www.youtube.com/watch?v=tcKRcRpNQkE&list=PLTds3QePYrWEWipwKkLmyNT4Tf_JTigM2

and

https://www.youtube.com/watch?v=yXk8c1w7rNo&list=PL1C4072533A16B807

MonroePoteet
04-08-2019, 08:53 AM
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

RebelHill
04-08-2019, 09:03 AM
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.

wesleycorgi
04-09-2019, 08:22 AM
Hi RH and mTp: Thanks again for your help. I am recreating both samples and can't figure out how you configure the bone (or is it the goal) such that the child bones will "telescope" into each other.

RebelHill
04-09-2019, 09:03 AM
The top bone targets the floor goal (rpr'd at the base position), second (or subsequent) bone(s), IK on Zpos.

wesleycorgi
04-09-2019, 09:36 AM
Thanks again, this was driving me crazy!