I recall from memory a different one… will check > On 24 Oct 2017, at 01:20, Jonathan Moore <jonathan.moo...@gmail.com> wrote: > > This post from SideFX's Jeff Wagner (Old School on the OdForce forum) it the > thing that really started to make things click for me ref the under the > workings of Houdini. It's about 7 posts down on this page. Essential reading > for all: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__forums.odforce.net_topic_17105-2Dshort-2Dand-2Dsweet-2Dop-2Dcentric-2Dlessons_-3Ftab-3Dcomments-23comment-2D10426&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=i9ql2Tfkb2ilOV4pVHvfPa3JbKjCZBLo38JmtvhRrxw&s=C3HI2xIwCgNxzXRMh5wSVDKg-2zHuh0Uq9yfN6yRBFs&e= > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__forums.odforce.net_topic_17105-2Dshort-2Dand-2Dsweet-2Dop-2Dcentric-2Dlessons_-3Ftab-3Dcomments-23comment-2D10426&d=DwMFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=IFOB2YDfjKIkLLTxmuU784akT-nMalYgo3M-Wf7C0J0&s=guDONrq1PA8zNDwKN7IjlO8wgyBqc1_U1Hsg5CI1M6o&e=> > > Enjoy. ;) > > > On 23 October 2017 at 20:23, Jordi Bares <jordiba...@gmail.com > <mailto:jordiba...@gmail.com>> wrote: > I see… indeed the documentation could move a bit faster but I guess is the > price we have to pay for such a turbo charged development cycles and support. > > In any case, I recall (although I can’t seem to find now) a post in Odforce > about network evaluation order and multi-threading that explain some of the > mechanisms at play that may shed some light for advanced users.. I could > barely follow some parts but there were some gems in it. > > I will try to find it again, I am sure I saved in my stash of > Houdini-stuff-that-one-day-I-will-need > > Enjoy! > jb > > >> On 23 Oct 2017, at 16:54, Ponthieux, Joseph G. (LARC-E1A)[LITES II] >> <j.ponthi...@nasa.gov <mailto:j.ponthi...@nasa.gov>> wrote: >> >> Jordi, >> >> Thanks. I think though I’m looking for a broader explanation of what the >> contextual differences are between the network levels. >> >> It turns out part of my confusion may be in part due to the current >> documentation. Today I discovered that the online docs are different from >> the installed ones. For example I discovered that the installed doc page is >> different than its online equivalent for >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.sidefx.com_docs_houdini_nodes_obj_-5Findex&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=i9ql2Tfkb2ilOV4pVHvfPa3JbKjCZBLo38JmtvhRrxw&s=9bMuf9jpwd-woiJFImFFpmqtDd3opE2DIrWLEPzKVwg&e= >> >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.sidefx.com_docs_houdini_nodes_obj_-5Findex&d=DwMFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=u77dOKhUM8I5W9ZDtgjaqAfpoAFh4Vv98S9cXQes4Bc&s=3WzLHhudfu-iCuZSnG30bFLuBY-ayjy-SfKTRymcoqM&e=> >> >> This online man pages clearly explains that Scene Level is strictly for >> spatial and hierarchical relations. Funny thing is there is no mention of >> this in the equivalent installed page. Or anywhere that I’ve searched in the >> installed docs for that matter. Apparently the docs are fluid and its best >> to use only the online version as they appear to be the most up to date. >> >> Time for me to start doing a lot of reading… >> >> >> -- >> Joey Ponthieux >> >> __________________________________________________ >> Opinions stated here-in are strictly those of the author and do not >> represent the opinions of NASA or any other party. >> >> >> >> >> >> >> <> >> 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 Jordi Bares >> Sent: Saturday, October 21, 2017 10:13 AM >> 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=i9ql2Tfkb2ilOV4pVHvfPa3JbKjCZBLo38JmtvhRrxw&s=99AUwc84PmWywzaOaXEo3DdX0yTWdZ6AodeGlrC9KV4&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=u77dOKhUM8I5W9ZDtgjaqAfpoAFh4Vv98S9cXQes4Bc&s=Fxpxs5Bh9EHuBuWO7qZmnbpALp1iC0sIeTStqCXGlLo&e=> >> <softimage@listproc.autodesk.com <mailto:softimage@listproc.autodesk.com>> >> Subject: Re: Houdini hierarchical organization >> >> 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 <mailto: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> >> [mailto: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=i9ql2Tfkb2ilOV4pVHvfPa3JbKjCZBLo38JmtvhRrxw&s=99AUwc84PmWywzaOaXEo3DdX0yTWdZ6AodeGlrC9KV4&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=XlsBp8GvwJkE-NA5nIAdVlrDz2EOY1Ef2EsZ2SKOAVs&s=yBbaZwFkSpwlDDezCPJd4Ta89esTQLLtSVzu95xorBU&e=><softimage@listproc.autodesk.com >> <mailto: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=i9ql2Tfkb2ilOV4pVHvfPa3JbKjCZBLo38JmtvhRrxw&s=99AUwc84PmWywzaOaXEo3DdX0yTWdZ6AodeGlrC9KV4&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=i9ql2Tfkb2ilOV4pVHvfPa3JbKjCZBLo38JmtvhRrxw&s=8-GAzkeI-TyZ9SC7aH7JmUkstKr9PLcQDxvgrmjk3U0&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 >> <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.
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
