PDA

View Full Version : Transform2 node.



hypersuperduper
03-14-2019, 10:41 AM
Is anyone here and expert on the transform2 node? How do I use it to get a “Same as item” behavior without referencing 3 items? Say I have null1 that is a child of null2 and both have non-zero rotation and translation. And say I also I have null3 in a different heirarchy. Using nodal motion and transform2 Can I get null1 to follow null3’s world position and rotation exactly without referencing null2? If I use all three nulls in the network I can do it, but I would like to do it with just 2 so I can reparent null 1 without messing around in the node editor. Before I understood what transform2 did I built my own custom compound node that does the same thing, but I need all three nulls there too.

MarkAH
03-15-2019, 08:02 AM
Try Follower maybe?
Only don't parent the nulls. Odd things happen if you do.
Put Follower as the motion modifier on two of the nulls and see how that works.
Then parent other things to the nulls. Something that renders.

MonroePoteet
03-15-2019, 09:53 AM
Don't know if it'll help in your scenario, but DPKit has a Parent node for getting information on an Item's parent. So, for example, I can set up the node network:

144428

This finds the parent node of the "Self" node and uses the parent's rotation as the current item's Position (again, just as an example).

DPKit is available here:

http://dpont.pagesperso-orange.fr/plugins/nodes/Additionnal_Nodes_2.html

and remember to support Denis financially if you can!

mTp

hypersuperduper
03-15-2019, 12:20 PM
Parent node is something I have wanted for forever, but would be nice if it output an ID. Thanks for the tip! It should probably do what I want. Should be native though. reusable Nodes setups would be far easier to setup with simple things like this.

MonroePoteet
03-15-2019, 01:20 PM
I agree completely. IMO, there are several nodes / features missing in the native LW node offerings which are completely debilitating for building cloneable / instanceable node networks. For example, the lack of these particular nodes / features have derailed my efforts, and continue to do so:


a "Self" selection in all node's Item pulldowns (and pulldowns are set to "Self" by default)

the node is applied to current Item for which the Node network is invoked rather than being hardwired to a specific Item


any pulldown in a node's panel interface should allow an input

e.g. if it requires an Item, should allow an Item ID input


a Parent node

returns the Parent Item for the current / given Item
can accept an Item as input for walking up the parent tree
outputs Parent Item ID


a Top Parent node

returns the top-most Item in the parent tree
outputs found ID


an "Item Index" node

e.g. "Item Index" for Light (3) would return the number 3 by parsing the Item's Name
returns 1 if no parenthesized index



mTp

hypersuperduper
03-15-2019, 02:33 PM
1 and 3 are a bare minimum. It seems like such a no-brainer to have this sort of relative referencing. The fact that it doesn’t exist makes me wonder if there isn’t some sort of fundamental limitation in the way lightwave nodes work.

MonroePoteet
03-15-2019, 03:11 PM
I don't think there's any inherent limitation in the LW node architecture since DPKit already provides the functionality for (1) and (3).

I'm working on a scene right now where I could sure use (5).

The Top Parent (4) is a self-relative way of setting up a "reference object" for any number of cloned object hierarchies, and I've written plug-ins using that method allow a bunch of cloned hierarchies to share common parameters set up in the Top Parent. I can then clone the Top Parent hierarchy, change its parameters, and affect all nodes underneath it (but NOT those of the other similar hierarchies), again without messing around in each cloned hierarchy's node editor(s).

re: (2), IMO if a node's interface panel requires / allows choosing any sort of options, those options should be available as nodal inputs as well.

mTp