It's approaching 1.30am here in the UK, so please forgive my inability to string a sentence together correctly in that last post... :)
On 24 October 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-2D&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=ujAviM_q7MrH-zCjByNM783ilAjORLaIXkahTP16vis&s=Q1UpdRpEyxb6ejlub6NohHp3Be3bPyZqtVjstSYC4g4&e= > op-centric-lessons/?tab=comments#comment-10426 > > Enjoy. ;) > > > On 23 October 2017 at 20:23, Jordi Bares <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> 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=ujAviM_q7MrH-zCjByNM783ilAjORLaIXkahTP16vis&s=WNzwQXsE_GYhrWnzng_jIGPKyIPKhvxRm6pieOw1fes&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 >> <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=ujAviM_q7MrH-zCjByNM783ilAjORLaIXkahTP16vis&s=PMQyvwjgCc_K-GiAhAB86cSmEu8Oio7wJauG4ZG0BPY&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> >> *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> 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:softim >> age-boun...@listproc.autodesk.com >> <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&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=ujAviM_q7MrH-zCjByNM783ilAjORLaIXkahTP16vis&s=jcOQHZFGAFUHTWuXXdd84m1Q4kpXJBDYctivHDT9o9Y&e= >> /forum/#!forum/xsi_list >> <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> >> *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> 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:softim >> age-boun...@listproc.autodesk.com >> <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&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=ujAviM_q7MrH-zCjByNM783ilAjORLaIXkahTP16vis&s=jcOQHZFGAFUHTWuXXdd84m1Q4kpXJBDYctivHDT9o9Y&e= >> /forum/#!forum/xsi_list >> <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> >> *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=ujAviM_q7MrH-zCjByNM783ilAjORLaIXkahTP16vis&s=xmv0k62s2GCTq1Ik8PA7fe769d7YdrDJFwgQkWaFv1g&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>: >> >> 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> 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 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. >> >> >> ------ >> 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. >> >> >> >> ------ >> 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.
