Jordi, Yes, I agree, it is a hierarchy, but the issue is the type of hierarchy it is.
The hierarchy that the Tree View presents is neither procedural nor spatial, but rather resembles that of a file system. The word I used earlier was “container view”. Tree View appears to be, for lack of a better description, more appropriately a “Path View” like Windows Explorer where it reflects the scene relative “file paths” of all objects in the scene. This is reflected in your example of the first torus when we use /obj/subnet1/subnet2/subnet1/torus_object1/tx to address x translation. This is similar to the absolute Dag paths in Maya I suppose, those seen when when using “ls –l”. Though it seems to employ a more absolute context in Houdini whereas in XSI or Maya you can address parameters from an object’s relative path. The confusion in Houdini, for me at least, seems to be that the hierarchy relative an object’s name path appears to be exclusive and different from any spatial hierarchy? Or is this just a skewed perspective as a result of studying the Tree View? The subnet example you provided appears to be capable of producing a hierarchy separate of the torus and null, but in the context of the view they would seem to be all part of the same hierarchy relative their absolute scene path names. The second torus and null would seem to be peers to subnet1 under obj for example. So it doesn’t seem that they are exclusive of the hierarchy at all, they’re just not part of an extended hierarchy. What I wanted to see was not the node path hierarchy but rather the articulation hierarchy, or spatial hierarchy, the way either Explorer or Outliner present it relative object ownership and spatial parenting. I’m learning the spatial hierarchy in Houdini has to be constructed in Network View buts its not clear from Network View whether these spatial relationships are “hierarchical” or “procedural” since they are being constructed in way that appears to be visually procedural, but it’s not clear if this is just an abstraction (at Network View::Scene Level) or if it is actually procedural. For example, the spatial relationships established at Geometry level (Network View::Geometry) do appear to be procedural, since piping things into a transform node for example can both transform and instance. This is not the same behavior at Scene level and at Scene level there appears to be very few nodes, if any, that appear to behave procedurally. That is, there appears to be very few operators at Network View::Scene level, only objects or generator nodes or subnet. I get the feeling that the “procedural” connections made at the Network View::Scene level aren’t really procedural at all, but rather only objective and/or spatial, though they inherently “look” procedural. This just isn’t clear. If that’s the case, the contextual behavior between Scene level and Geometry level provides some degree of confusion because the underlying behavior of each doesn’t match the similar visual context they are both using which suggests procedural relationship and modification. That’s why I wanted to see a clear spatial hierarchy representation, vs a path hierarchy or “procedural hierarchy”, so I could determine what was acting procedurally on each other vs what was related spatially, or both for that matter. I guess the primary concern I have is in determining what is the best practice for setting up any spatial hierarchies, and for that matter, where can spatial hierarchies even be set up and how do they differ from context to context (Scene vs Geometry for example). Until a couple days ago I thought all network connections in Houdini were actually procedural. I’m now questioning whether that is the case or are some of these connections that look procedural, are they only abstractions for the sake of establishing spatial hierarchy? If that is the case, which ones are abstractions and which ones aren’t? How and what do I use to establish an awareness of what is being edited by an operator vs what is taking only spatial transformation or spatial governance? Is any spatial ownership actually occurring at all in Houdini, like in XSI or Maya, or is my current assumption incorrect and are all spatial relationships actually procedural but more similar to constraints? I could see that to be the case at the Geometry level but that’s not the way it appears at the Scene level. None of this is very clear or I’m just not looking in the right place yet ☺ And yes, “procedural hierarchy” is probably a misnomer. Since in theory a procedural tree isn’t supposed to be rank based but rather restricted only by IO type. Any node at the bottom should be capable of feeding back to any node above it that at a minimum matches or uses its IO classes, so ownership (rank) should be irrelevant. I guess that’s why I’m finding the use of a procedural tree to establish spatial relationships, which are rank based, to be somewhat unnerving and counterintuitive. It seems to go against the whole grain of proceduralism. Unless there’s something about the way Houdini is doing this that I don’t quite grasp yet? BTW, your Softimage to Houdini document (all 849 pages of it!) is just fantastic! I hope you plan to be doing more with it. Joey From: [email protected] [mailto:[email protected]] On Behalf Of Jordi Bares Sent: Thursday, October 19, 2017 6:40 PM To: Official Softimage Users Mailing List. https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_forum_-23-21forum_xsi-5Flist&d=DwIGaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=cTaFtUQMi3XnzvtSpI6AXKpDHG1-P_3-giRMX_N7Ias&s=GYDB7cLs6ZIfwJJZGyMAKggSzfIlWVMkY4g-7p4q32s&e= <[email protected]> Subject: Re: Houdini hierarchical organization Just to clarify… Hierarchies are fully represented in the Tree View, the content of an object too but of course it is impossible to draw in a hierarchical way something that is parallel. For example, in XSI you have an object (that would be your Houdini Object) and the operator stack in a linear fashion (which is your SOPs -with regards to geoemtry- and in Houdini is non-linear so you can’t see it the same way). Nevertheless you can still see all those SOPs nodes arranged in there. BUT When you are in your OBJ and you plug one object to another you are NOT building a hierarchy, you are just passing data from one node to another, the behaviour in many cases is exactly like a hierarchy, but remember you are just passing data. That is the reason you don’t see it graphed in the Tree View. Try this 1) Create an torus 2) create a subnetrowk 3) create another one 4) create another one And now have a look at the TreeView… that IS a hierarchy. Now try this 1) create a new torus 2) create a null 3) plug the null to the torus so the null affects the SRT data on the torus Check and you will see that IS NOT a hierarchy although it behaves like one. I hope that helps jb On 19 Oct 2017, at 19:54, Ponthieux, Joseph G. (LARC-E1A)[LITES II] <[email protected]<mailto:[email protected]>> wrote: Olivier, Yes, that’s what I was looking for. Though it really isn’t Tree View but rather Network View in List Mode . Apparently its not possible to make Tree View behave the way I was expecting it to. But I guess there is a greater advantage to having Tree View and Network View in use simultaneously as long as you understand that Tree View is neither procedural nor spatial in its representation. This is useful, and it confirms my initial perception of Tree View. It also confirms that reconciling the multiple contexts that Network View apparently governs, procedural vs spatial for example, is going to take a bit more effort than I originally anticipated. Thanks Joey From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Olivier Jeannel Sent: Thursday, October 19, 2017 2:25 PM To: Official Softimage Users Mailing List. https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_forum_-23-21forum_xsi-5Flist&d=DwIGaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=cTaFtUQMi3XnzvtSpI6AXKpDHG1-P_3-giRMX_N7Ias&s=GYDB7cLs6ZIfwJJZGyMAKggSzfIlWVMkY4g-7p4q32s&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_forum_-23-21forum_xsi-5Flist&d=DwMFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=HeGph8Xh5ttXXXkUA1HeWYPBLG2Qmno5epbEQVMdgfg&s=HSr8sPtL0vRAqzlfGZqIuieD_U92SvH8KA-P1XezYi8&e=> <[email protected]<mailto:[email protected]>> Subject: Re: Houdini hierarchical organization Not sure I understand you well Jopseph, but here a little tutorial with som "gem" about the tree view https://urldefense.proofpoint.com/v2/url?u=https-3A__vimeo.com_233232773&d=DwIGaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=cTaFtUQMi3XnzvtSpI6AXKpDHG1-P_3-giRMX_N7Ias&s=wSCg5tLAcvRhPktwcfXY2ZtEdJSvm8ZeKXeoQnu1b44&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__vimeo.com_233232773&d=DwMFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=OKef69kBqPJXx68i4heEfHR30NI_NUub2sbaNk2wwws&s=LxaiEbXJ3vm44MM6t9mv5vJ_ShpJjcEj5uTiecLtIkM&e=> Apologies if I'm way out of topic. 2017-10-19 20:08 GMT+02:00 Jonathan Moore <[email protected]<mailto:[email protected]>>: Apologies for the rushed response as I'm heading out for an event. However, the tree view in Houdini is best viewed simply as an alternative data visualisation (best utilised a-z filtering). It's not an organisational view or a place where you manipulate data. Transform hierarchies should be created in the Network Editor and you can quickly traverse nesting structures via the tree view. In simple terms the Network Editor is where all major scene manipulations take place and the Tree View is provided to aid navigation in complex node structures. At least that's the way I've always worked in Houdini. ;) jm On 19 October 2017 at 16:47, Ponthieux, Joseph G. (LARC-E1A)[LITES II] <[email protected]<mailto:[email protected]>> wrote: Hello folks, I figured people using Houdini on this list would understand the context of this question better, coming from a Softimage background, rather than an exclusive Houdini background. I’ve been trying to learn Houdini the past several months and I’ve suddenly realized something that has me questioning some things that may very well be misconceptions on my part, about the interface. To get right to it, is there a way to make Tree View represent object hierarchical parenting relative transform relationship? I’ve discovered that I can create transform relationships just fine in Network View, but that it has also taken some effort to realize what happens in Network::Scene is both similar and dissimilar to what happens in Network::Geometry and neither is exactly reflected the same way in Tree View. A big part of the dissimilarities that I’m starting realize differ on how, and when, a network produces transform relationships versus when it permits procedural editing of object data. It seems that Tree View only depicts a kind of “container view” context. Or rather, what is “inside” something else as opposed to what is the parented relationship by transform or articulation context. Tree View is great for finding and selecting something but more or less seems ineffective in setting up a hierarchy of objects affected by transformation relationships. I’m finding the only place I can do that is in Network View, and that the nature of this changes in context somewhat depending upon Network View’s active object context, whether its Scene or Geometry for example. Which gets me to my next question, what and where is the proper way in Houdini to set up hierarchical relationships of transform context? (Parenting for articulation purposes) I find I can use nulls or geometry in Network::Scene to do this but then I have to use transforms in Network::Geometry to do the same thing. But transforms in Network::Geometry also permit instancing of the geometry as well as transform relationships and the entire behavior of the network in Geometry seems to permit a higher degree of proceduralism than does the one at Network::Scene level. While none of this is necessarily problematic, it more fundamentally raises the question of “what is best practice?”. Should Geometry nodes be limited to only creating static objects and hierarchical articulations established only at Scene level? If so, what nodes are best used for transform hierarchies? Or is reasonable to arrange structures in Geometry nodes that permit transform articulations? The concern here is, of course, would such structures end up inadvertently duplicating or instancing geometry where I think I am setting up transform articulations instead? And am I left with the ability to create transform articulation hierarchies only in Network View and unable to create articulation hierarchies in Tree View? All thoughts or suggestions in this regard would be very welcome. -- Joey Ponthieux __________________________________________________ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. ------ Softimage Mailing List. To unsubscribe, send a mail to [email protected]<mailto:[email protected]> with "unsubscribe" in the subject, and reply to confirm. ------ Softimage Mailing List. To unsubscribe, send a mail to [email protected]<mailto:[email protected]> with "unsubscribe" in the subject, and reply to confirm. ------ Softimage Mailing List. To unsubscribe, send a mail to [email protected]<mailto:[email protected]> with "unsubscribe" in the subject, and reply to confirm.
------ Softimage Mailing List. To unsubscribe, send a mail to [email protected] with "unsubscribe" in the subject, and reply to confirm.
