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-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=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=ScFIn7D4C28koShcB40kW_jG5xL8zYOKII9bGEUKYCE&s=bFWjwFCeLVZGKXZii1JxLho9Ae8s7KLQJWp4aJUY8yg&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 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.

Reply via email to