I recently walked some SideFX folk through the niceties of Soft's Explorer view. They are open to elucidation but the problem is that they don't always realise how broken Houdini really is when it comes to animation UX and scene management utility in general.
Whenever I return to Soft (generally to make use of Eric M's peerless tools) the Explorer is always such a welcome sight (especially if I'm returning to a setup I've not used for many months). It's amazing how much utility the Soft engineers managed to fit into that single interface. Of all the things Autodesk have pilfered from Soft for inclusion in Maya/Max the UX of the Soft Explorer would have been top of my list. Even amongst Maya loyalists, there aren't many fans of the Outliner! On 20 October 2017 at 10:10, Jordi Bares <jordiba...@gmail.com> wrote: > That would make the TreeView very useful… nice ideas! > > On 20 Oct 2017, at 09:42, Tim Bolland <tim_boll...@hotmail.co.uk> wrote: > > I have campaigned for the tree view to allow control over hierarchies and > exhibit other useful features similar to Soft. These would include > manipulating parent/child relationships, duplicating objects and deleting > objects. I was also asking for an option to see and edit parameters on the > object node (such as kinematics and custom promoted parameters). > > They seemed interested in this and have submitted and RFE for the changes > (Submitted > as RFE (ID=85595)), so fingers crossed this is coming in a future update! > > Cheers, > > Tim > > > > ------------------------------ > *From:* softimage-boun...@listproc.autodesk.com < > softimage-boun...@listproc.autodesk.com> on behalf of Ponthieux, Joseph > G. (LARC-E1A)[LITES II] <j.ponthi...@nasa.gov> > *Sent:* 19 October 2017 19:54 > *To:* softimage@listproc.autodesk.com > *Subject:* RE: Houdini hierarchical organization > > 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-bounces@ > 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=zpbQ19pqnSq50uFMoevPIwf0IaYYUgJ5FLaUr2bOuss&s=kXAW8m03MPYrQXkdpU0RUbPwM6vjb8LxiwnEnxI9wpE&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=ScFIn7D4C28koShcB40kW_jG5xL8zYOKII9bGEUKYCE&s=ohuEXEToqJg7X6ZaqlvKeAaQsLvTbYU7l5UKLKImT48&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=zpbQ19pqnSq50uFMoevPIwf0IaYYUgJ5FLaUr2bOuss&s=xOQFKsXfsiesQroWpEC6HtaJjigzvZv1f8AP9phkiD0&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.
