Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2026 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2026 Daz Productions Inc. All Rights Reserved.
Comments
Thanks, I see that now. But, I don't understand how zeroing the child position will move the child object to the parent's bone. What I see when I "parent not in place" in the scene pane, is that the child object origin moves to the position of the parent bone. In that case, the translate values shown in the Parameters pane for the child are not 0,0,0. I am trying to adjust the sample script you posted to replicate the behavior of "parenting not in place" in the scene pane.
So, I added this to the end of the script, and it moves the child object origin to the parent's bone, like parenting in the scene pane does. But it does not adjust rotation the way parenting in the scene pane does, so I am not 100% there yet.
// Set child's transforms
var oChild = aNodes[ n ];
oChild.setWSPos( oParent.getWSPos() );
I may sound as dumb as a rock here, but is there a way to make a script for turning parent in place on and off?
I don't follow. 'parent in place' when parenting from UI is a selection box. And it remembers your last choice.
Now if you want a script to 'move to parent' for object already parented, then yes. The other way around, i doubt because i don't think there is a record about original position once the parenting is done (except undo)
If drag-and-drop to parent one node to another, both with non-zero locations, then for me all the child transforms are zeroed and it sits on top of the parent's centre point. The script keeps the values non-zero, so the child is now offset from its new parent just as it was from the world centre (or its old parent).
Just zeroing the local (not WS) transforms will mimic the drag-and-drop behaviour. So this just worked for me with position and rotation (Scale is left as an exercise for the reader :P )
I can't immediately see that there is a script command for this, though it may be possible to trigger it as an action.
I am using DS 4.24.0.4. This doesn't work for me; it does not mimic dragging and dropping the prop onto the parent bone in the Scene pane. I deleted the code I had added and added your new lines of code right after the oParent.addNodeChild as shown above. It changes the orientation of the prop in the viewport, but does not move it to the parent's target bone. If I drag the prop to the parent bone in the Scene pane, with Parent in Place previously unchecked, the prop does move to the parent's hand and the orientation changes. So the script and the drag and drop do not have the same result for me.
Also, why does local have to be declared var over and over? Once the variable is declared, can't you just reassign it to a new value with the next get command? My total lack of Daz script knowledge is showing. Thank you for your patience.
So, I tried adding my two lines of code to setWSPos after your local transform lines of code, and that seems to make the script work like the drag and drop. I don't understand why it works differently for you and me.
Are youusingtrue or false for Parent n Place (teh second parameter addNodeChild)? It sounds like true, which will indeed leave the prop where it was and then chnaging its world space location to that of the parent wil move it there. My additions are to make the false case equivalent to Parent in Place being off.
I am using false. This is my whole script:
// Snap parent script, which will parent a node to a bone and align it too. For a simple parent anythings-that-aren't-a-bone in place to anything:
// Get all selected nodes in the scene
var aNodes = Scene.getSelectedNodeList();
// Get the primary selection - usually the last node selected
var oParent = Scene.getPrimarySelection();
// go through the list of selected nodes
for ( var n = 0 ; n < aNodes.length ; n++ ) {
// skip the parent-to-be, we can't parent it to itself
if ( aNodes[ n ] == oParent ) {
continue;
}
// We can't change the parents of bones, so skip them
if ( aNodes[ n ].inherits( "DzBone" ) ) {
continue;
}
// Parent the current node to the parent, with Parent in place on -
// replace the true with false to have it snap
oParent.addNodeChild( aNodes[ n ] , false );
// Set child's transforms
var local = aNodes[ n ].getXPosControl();
local.setValue( 0 );
var local = aNodes[ n ].getYPosControl();
local.setValue( 0 );
var local = aNodes[ n ].getZPosControl();
local.setValue( 0 );
var local = aNodes[ n ].getXRotControl();
local.setValue( 0 );
var local = aNodes[ n ].getYRotControl();
local.setValue( 0 );
var local = aNodes[ n ].getZRotControl();
local.setValue( 0 );
var oChild = aNodes[ n ];
oChild.setWSPos( oParent.getWSPos() );
}
Here are some screenshots. This is from DS 4.24.0.4. I have the node select tool active during these tests, if that matters.
SS1 Water glass added to scene with posed LowPi character. Water glass loads at world center and is not parented to anything.
SS2 Drag and drop water glass onto lFingers2 LowPi bone in the Scene pane. Water glass jumps to LowPi left hand fingers2 and is properly oriented.
SS3 Script is executed with Richard's local transform lines of code added (ONLY those lines of code added). Water glass is reoriented, but does not jump to LowPi finger bone location.
SS4 Script is executed with Richard's local transform lines of code and my two world position lines of code. Water glass viewport position and parameter values look just like the drag and drop results.
Oops, I'm going to redo the screenshots. I didn't capture enough the first time. OK, fixed now.
Here's another set of screenshots. This is DS4.24.0.4 This is with selecting the water glass and right clicking on it in the Scene pane and selecting to change its parent to LowPi lFingers2 bone. The glass moves to the fingers as desired, just like the drag and drop (and the script when it sets both local and world space positions).
OK, weird. It works with props but with bones it goes to the figure centre point - that is not the way I thought it worked until recently. I am now thoroughly confused, but sorry for leading you up the garden path.
I'm willing to travel any paths with you. They usually lead to good places. Even here, we both discovered some things along the way.
Thank you, that is a commendably glass-half-ful approach. I've pojnted these inconsistencies out to Daz, I don't know what will happen as a result.
In Rob's spare time (

) he can update the scripts to match the latest Daz Studio implementation.