Results 1 to 7 of 7

Thread: Transform2 node.

  1. #1
    Registered User
    Join Date
    Sep 2015
    Location
    Sweden
    Posts
    508

    Transform2 node.

    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.

  2. #2
    Registered User MarkAH's Avatar
    Join Date
    Feb 2008
    Location
    Green Valley, AZ
    Posts
    41
    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.

  3. #3
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,687
    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:

    Click image for larger version. 

Name:	01_DPKit_ParentNode.jpg 
Views:	17 
Size:	963.8 KB 
ID:	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/pl...l_Nodes_2.html

    and remember to support Denis financially if you can!

    mTp

  4. #4
    Registered User
    Join Date
    Sep 2015
    Location
    Sweden
    Posts
    508
    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.

  5. #5
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,687
    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:

    1. 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

    2. 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

    3. 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

    4. a Top Parent node
      • returns the top-most Item in the parent tree
      • outputs found ID

    5. 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
    Last edited by MonroePoteet; 03-15-2019 at 01:25 PM. Reason: typo; clarification

  6. #6
    Registered User
    Join Date
    Sep 2015
    Location
    Sweden
    Posts
    508
    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.

  7. #7
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,687
    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

Bookmarks

Posting Permissions

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