Mmm… if you try (forgive me if I am getting it wrong) to represent data in the same way in Houdini you may struggle as it is a different principle.
Only subnetworks can store objects, what lies inside an object is the procedural network that is evaluated. Therefore, if you have a table with four legs, they can be “sons” of a subnetwork, but the legs can’t be “sons” of the tabletop. You may pass data from one to the other and the behaviour will be similar to that of a hierarchy but of course, this is not and therefore won’t be represented as such in the Tree View. In terms of the Tree View limitations, I agree they could bring some ideas from XSI into it but let’s not forget, representing a parallel workflow (SOPs for example) in a linear hierarchical way is simply not possible. Which is the same issue you find in XSI with ICE trees where they are represented by a operator in the op stack and you need a special viewer. I hope I understood well your explanation. jb PS. With the guides… I am on it… but the problem is that I am super busy right now so finding time is proving very very very difficult. > On 20 Oct 2017, at 20:09, Ponthieux, Joseph G. (LARC-E1A)[LITES II] > <j.ponthi...@nasa.gov> wrote: > > 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 J > > 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: softimage-boun...@listproc.autodesk.com > [mailto:softimage-boun...@listproc.autodesk.com] 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=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=XlsBp8GvwJkE-NA5nIAdVlrDz2EOY1Ef2EsZ2SKOAVs&s=yBbaZwFkSpwlDDezCPJd4Ta89esTQLLtSVzu95xorBU&e= > <softimage@listproc.autodesk.com> > 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] > <j.ponthi...@nasa.gov <mailto:j.ponthi...@nasa.gov>> 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: softimage-boun...@listproc.autodesk.com > <mailto:softimage-boun...@listproc.autodesk.com> > [mailto:softimage-boun...@listproc.autodesk.com > <mailto:softimage-boun...@listproc.autodesk.com>] 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=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=XlsBp8GvwJkE-NA5nIAdVlrDz2EOY1Ef2EsZ2SKOAVs&s=yBbaZwFkSpwlDDezCPJd4Ta89esTQLLtSVzu95xorBU&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=><softimage@listproc.autodesk.com > <mailto:softimage@listproc.autodesk.com>> > 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=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=XlsBp8GvwJkE-NA5nIAdVlrDz2EOY1Ef2EsZ2SKOAVs&s=VL4K_qRyRMP4-fJ-UqaYIQyTvcevnqFcUShM7DcHoHA&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 <jonathan.moo...@gmail.com > <mailto:jonathan.moo...@gmail.com>>: > 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] > <j.ponthi...@nasa.gov <mailto:j.ponthi...@nasa.gov>> 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 softimage-requ...@listproc.autodesk.com > <mailto:softimage-requ...@listproc.autodesk.com> with "unsubscribe" in the > subject, and reply to confirm. > > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com > <mailto:softimage-requ...@listproc.autodesk.com> with "unsubscribe" in the > subject, and reply to confirm. > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com > <mailto:softimage-requ...@listproc.autodesk.com> with "unsubscribe" in the > subject, and reply to confirm. > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com > <mailto:softimage-requ...@listproc.autodesk.com> with "unsubscribe" in the > subject, and reply to confirm.
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
