PDA

View Full Version : Parent in place not working properly



gordonrobb
01-10-2009, 02:24 AM
OK, I am losing my mind and I need someone to try this for me.

Load any object. Move it so that the pivot/centre is not at the origin (0,0,0).

Create a null.

Now here is my understanding. If you have 'parent in place' selected and then parent the null to the object, the null should not move. - when I do this, this is exactly what happends. Yipee.

However, as I understand it, if you do not have 'parent in place' selected, and parent the null to the object, the null should snap to the position of the objects pivot point. - when I do this, this is not what happens, the null stays where it is.

Can someone try this themselves and tell me what result they get, as it is driving my completely batfink.

Oh, and I am using 9.5

UnCommonGrafx
01-10-2009, 08:50 AM
Everyone will get the same result as you: the null is becoming a child at its present position. If you zero out the position fields, it will snap to the null.

Your mind is intact.

gordonrobb
01-10-2009, 11:01 AM
Not quite. What you are describing is what happens when 'parent in place' is selected.

I have tested the problem further. With 'PiP' deselected, the null moves to what the origin of the object is. So if the object has been moved, the null moves. My problem is that if the pivot for the object is not at the origin of the object, the null does not snap to the pivot - as I am 100% sure it used to.

UnCommonGrafx
01-10-2009, 11:20 AM
I just tried it; it still works as you say it should.
Parent one to two in this scene:
http://uncommongrafx.com/examples/ParentINPlace.zip

You can see that the behavior is as you say it should be.

gordonrobb
01-10-2009, 11:26 AM
Yeh, but your parenting a null to another null. A null cannot have a pivot point that is not a it's origin.

Create box. Move it's pivot away from oriigin in modeller. Then try it. The null moves to where the objects origin would be, not where it's pivot is. This is not what should happen.

UnCommonGrafx
01-10-2009, 02:34 PM
But that IS the pivot unless you issue the "Move Pivot" command. Your moving the box off the origin does nothing for the pivot: it remains at the origin.

gordonrobb
01-10-2009, 03:44 PM
This is my point I am moving the pivot off the origin in Modeller. And it has no effect when parenting (not) in place. I will upload a small scene in the morning to explain better.

UnCommonGrafx
01-10-2009, 04:17 PM
I get it. Something is amiss.
A scene inside the following zip shows the problem: layout ignores that the modeler pivot has been reset. Or, the code in PIP isn't paying attention.
http://uncommongrafx.com/examples/ParentINPlace.zip

That would be quite a hassle with rigging machines.

That and it then won't follow the pivot at all, never snapping to the modeler-augmented pivot position.

gordonrobb
01-10-2009, 05:23 PM
Excatly the problem. The way I wsa taught to rig hydrolic pistons almost requires the ability to have the null snap to a defined pivot point. Bugger. Will fire up 9.3 tomorrow to see if it did indeed work the way I expected it before, then try and report it to Newtek.

Tom Wood
01-10-2009, 05:44 PM
I'm interested in this issue, but with a different twist. My character objects have 11 layers that are all centered on the origin in Modeler. I've moved the object off-center in Layout and parented everything to the first layer. If I add a new layer in Modeler and try to add it to a Layout scene, it won't parent in place relative to the object. It loads into the scene relative to the origin. My workaround has been to create what I need in a new layer in Modeler, and then move it to one of the existing 11 layers that position correctly in Layout. But I'd really like to be able to add new layers in Modeler and have them parent in place relative to the object (not to the origin) in Layout.

evenflcw
01-11-2009, 05:45 AM
I think everything is as it should and you guys are just have the wrong idea about what (nopip) parenting is about. Your illusion needs revision. :) Mind you, the way you think it should works could be the proper way, but the way it does work currently IS sound.

Fact: When you load an object which has had it's pivot altered in modeler, the object will have it's position automatically offset in layout by the same amount. If the pivot was set at 1. The position will also be 1. (no need to use xyz, consider 1 to be <1,0,0> if you want).

In uncommongrafx examples (boiled down; mesh location really has no importance, but oddly the off center mesh was abit confusing):


boxA position is 0 with pivot at 0; nullA position is 0. Parenting nullA to boxA, will keep nullA in the same world position as before, which happens to coincide with boxA pivot (mainly because null had no local offset).

boxB position is 1 with pivot at 1; nullB position is 0. Parenting nullB to boxB, will keep nullB in the same world position as before, this does not coincide with boxA pivot as before! I'm ok with that. :)

I note that you expected the null to snap to the pivot in both situations. But there is something else instead that is equal after parenting! Parenting is not about snapping to pivots. It's just about math. That items seem to snap to the new parents pivot is just a biproduct, a biproduct that only happens in some situations, when parent pivot is at X and child position is X (ie, 0 and 0 or any other value). But in all situations the equation is simply <i>item world position = parent position - parent pivot + item position - (item pivot)</i>. Nothing more, nothing less.

Above situations:
A.0-0+0 = 0
B.1-1+0 = 0

and for completeness:
C.1-0+0 = 1
D.0-1+0 = -1

In B, the parent is basically offset once (via the pivot), and then back again (via position) resulting in something equal to A.
In C the null "snaps" to the pivot as parent pivot and null position are both 0. In D the null doesn't "snap" to pivot because pivot and null position doesn't match. It would be illogical and inconsistent if it did snap to the pivot here as it did in A, B and C.

This post got really stuffy. Sorry. :)

evenflcw
01-11-2009, 05:59 AM
Btw, this is one reason I never rig using discrete objects instead of bones. With bones you can always see where the pivot is and where it is pointing (unless you alter pivot position and pivot rotation, which I also refrain from).

Another reason is that Modelers notion of pivot is surly lacking compared to layout. It does not have rotation, and as TomWood mentioned, Layout prefers to bring them in with position=pivot so they are positioned just as they were in Modeler.*

Using a single object and 100% weights for bones is so much cleaner, easier to work with and easier to reuse!


*@TomWood: So perhaps just select all items after load and set position to 0,0,0 for all items!?

gordonrobb
01-11-2009, 07:53 AM
I got a bit confused reading your post.

What I am trying to, I have found vital in the past to rigging multi layered objects (hard body objectst that I will use IK, not bones). I adjust the pivot points of each layer according to where it will pivot. Each layer obviously needs to pivot in a different place in a complex piece of machinery. This works fine and has had no problems. the parenting of these objects works fine as, after setting it all up in multi layers in Modeller, I do not want any of the bits to move when I pivot.

However, the problems when I want to set up nulls and have them placed EXACTLY where a particular layers pivot is. Previous to 9.5, I would deselect PiP, Parent and the null would move to the pivot point of the parent layer. I would then select PiP and unparent. The null would then be exacely where I want it. This no longer works. It is not working as it should because what happens is the null snaps to the origninal origin of the layer, not the pivot. This is not about object positions, it is about Layout not recognising the new pivot point (which it shows quite happily, and is the point the object rotates round) when it snaps the null to the obejct.

This is definately not working as it should.

evenflcw
01-11-2009, 08:41 AM
I'm well aware of the (ab)use of parenting and unparenting to snap one item to another items (pivot) position. But are you really sure when you performed this in the past you did it on objects which had there pivot AND position altered?

In any case, you got 9.5, use the new interactive snapping: ftp://ftp.newtek.com/multimedia/movies/LW_9/Layout_Snapping.mov . It does not care about the math as explained earlier, it simply snaps to the pivots world position.

UnCommonGrafx
01-11-2009, 09:16 AM
With all of what you say in mind, it still seems busted as one can't snap to that object whose pivot has been offset in modeler.
And how can it be abuse of a function of the tool? I guess I don't understand the notion of doing away with something that works "as advertised".

I looked at your math and it isn't jiving with what the scene showed me; that is to say, your math is wrong or LW isn't behaving even as you describe.
Layout isn't recognizing a moved pivot in Modeler. What this means is that one can't set up some machine, with all parts in place with pivots placed as needed, load into layout and start parenting nulls to those positions. This seems an absurd way to work when the previous methodology worked.

I guess I don't see happening what I want to happen such that I will submit a bug for it.

gordonrobb
01-11-2009, 11:41 AM
I have 9.5, and it does not snap as shown in the video, is this a 9.5.1 (beta version) feature?

Just booting my old machine up to test the fucntionality I suggested was in the older levels

gordonrobb
01-11-2009, 11:55 AM
Cant get my old machine to load up. Will need to find it's old key board and mouse for some reason. Intersted in this snap inplace thing though, cna someone tell me if its a 9.5.1 feature?

Castius
01-11-2009, 12:17 PM
Well i tried this on 8.5 and 9 and 9.5. I can not get a null to snap to the pivot using parenting. I don't know how you would have had it working before. But in the end it's not workign so it doesn't matter.

I would submit it as a bug. LW is not reading the pivot when it does the math for the parent. It is only using the keyframe data.

gordonrobb
01-11-2009, 12:19 PM
What I don't understand is that if you have a box which is centred on the origin in modeler, and send it to layout, it shows up as at position 0,0,0 which you would expect. If you then move the pivot in Modeller to 1,1,1 say and send it to layout the box is phisically in the same place (as expected) with the pivot where I put it and layout says the box is at 1,1,1 which is what I would expect. Why then does the null not use that position to snap to, instead of 0,0,0

evenflcw
01-11-2009, 04:20 PM
Ok, maybe I should not have written "abuse" - too much negative connotation. I really just meant to say that this (common) use of the function was unintended and unplanned. It doesn't make it less useful or wrong to use it like that, but you shouldn't expect it to always work for B, when it was made for A. Parentings main product or even secondary product is not "snapping to pivot"! The math could be wrong, but I haven't seen a setup yet that disproves it, so I'd loved to see that scene, UncommonGrafx. Although I only came up with that yesterday, so haven't done alot of tests.

gordonrobs post above really contains everything. Initial position is <0,0,0>. Gordon changes pivot to <1,1,1> in Modeler. When he loads it in Layout, Layout sets the position to <1,1,1> to counteract (if it didn't, the meshs physical position would not match that in Modeler). Two operations occured! Not one! If there had only been one operation the net sum could be <1,1,1>. But fact IS Gordon moved it AND Layout moved it back again, net sum IS zero. I'll rest now. :)

gordonrobb
01-11-2009, 05:34 PM
gordonrobs post above really contains everything. Initial position is <0,0,0>. Gordon changes pivot to <1,1,1> in Modeler. When he loads it in Layout, Layout sets the position to <1,1,1> to counteract (if it didn't, the meshs physical position would not match that in Modeler). Two operations occured! Not one! If there had only been one operation the net sum could be <1,1,1>. But fact IS Gordon moved it AND Layout moved it back again, net sum IS zero. I'll rest now. :)

You say there are two operations. I move the pivot, and when layout loads the object the object is where it was and the pivot is in the new position. The ojbects position according to layout, is where the pivot is. How is this two operations? Don't get it.

Can someone answer thequestion about object Snap thing that is in the video, what version of lightwave is this feature supposted to be in?

UnCommonGrafx
01-11-2009, 06:00 PM
Dan, I did that dance, too. ;)

Try this on as the problem: if you've reset the pivot in modeler for the purpose of taking advantage of this snap-to functionality, it won't work.

In Layout, based on the math notion, the snap to position is the origin, not the reset pivot spot. Used to be that this moved pivot became the origin, doing the math to zero the numbers on load. Maybe institutional memory isn't funtioning right ;) but this is what I recall.
I believe this is the result of the recent fix for local to world coords.

Funny: things won't snap to this new modeler-decided pivot but this object will properly attach/snap to other objects.

Castius
01-11-2009, 06:57 PM
I believe the new snap to pivot is in version 9.6.

If you change the pivot in modeler with the object loaded in layout with the hub. You need to reset the pivot in layout to read the changes from modeler.

Regardless i think you should report this as a bug. Most of us have just gotten used to not moving pivots in modeler or layout because of so many problems LW has with it. It doesn't mean it shouldn't work. Many pivot issues were fixed in LW 9.5/9.6. It can't hurt to try to get one more fixed.

gordonrobb
01-12-2009, 02:05 PM
Just tried this, and sure enough the snap to to pivot snaps to the adjusted pivot. Cool.