Duh. Got the order of the 3 points wrong there, but I’m sure you figured that out ;)
> On 7 Apr 2017, at 20:02, Andy Nicholas <a...@andynicholas.com> wrote: > >>> So now we have 'compounds' with custom port names, now how/why are we not >>> seeing dozens of those everywhere? > > >>> And in you opinion, what could be preventing that, or what could be >>> streamlined to promote that. > > > TLDR; Sharing HDA’s properly in a way that doesn’t cause screw ups is hard, > and most people are scared to start trying. > > In more detail: > > Basically there are three barriers of entry: > 1) The process of making an HDA is a fairly technical and involved > process if you want to do it right. > 2) It also requires a level of understanding as to what you’re doing > with versioning and operator naming. > 3) If you want to have ease of re-use of HDAs, then you need to store > them on disk rather than embedding them purely within a scene. That means > that you really need to have a well organised and tightly managed > environment. > > > Okay, so looking at Barrier 1, there are basically two ways to name an HDA: > Option 1) Call it something like “my_vop_node” and give it a version > number in the Type Properties: Version parameter. There can only ever be ONE > version present in your scene. But believe it or not, the way Houdini decides > which version to use by default, is to pick the version with the latest > modified date on disk, **regardless of the version number you entered**! > Yeah, I was quite taken aback by that, but that’s what it does. So in my > book, that’s really not ideal. In a complex pipeline, there are just too many > ways a file may have it’s modified date changed at any time. Imagine if that > happens halfway through your render. No thanks! > Option 2) Call it “com.silib::my_vop_node::1.0.0” which is the more > recent "namespacing" format. This is much better, as now Houdini at least > respects the version number in the name properly (it now ignores the one in > the Type Properties: Version parameter). It also means that Houdini allows > you to have multiple versions of the same node in your scene, yet it still > sees them all as having the same type name “my_vop_node”. The namespacing > helps avoid name clashes with HDAs that are built-in or in other libraries. > All very handy. > > So number 2 is obviously the way to go, but I always have to look the details > up with how it handles versioning. > > > For Barrier 2: > Let’s say you’ve written a SOP HDA to process some geometry in some way. > There are potentially a lot of things you need to handle to make it feel like > a proper Houdini node, some examples: > * Does it tidy up the temporary attributes and groups you created in the > process? > * Does it preserve the original attributes and groups in an intuitive way > through to the result? > * Does it support Polygon Soups? > * What happens if I pass in NURBS, a volume, or packed primitives? Does it > ignore them, delete them, or error? > * Did you remember to write python code for doing the proper picking in the > UI for your “Group” parameter you created? > * Have you hooked up the handles for the UI? > * Don’t forget to write your help card! > > It’s nowhere near as quick and easy as in ICE. > > For Barrier 3: > Let’s say you make a new HDA. You might start with putting it in your local > user preferences. That’s fine for about 10 minutes until your mate Johnny > wants to use it. So you email him the HDA (eeek!) and he puts it in his user > preferences too. Great. So that all works fine until Johnny decides to change > your HDA and forgets to tell you. Now his scene behaves differently to yours! > Okay, so not a good strategy. > > Maybe we put it in a central location where everyone can access it? Much > better, right? Yep, as long as you remembered to write protect the file after > so someone doesn’t accidentally unlock it, make changes and save over the > top, thereby affecting everyone’s scene. > > So that’s okay until someone wants to have a job specific version. Or even a > shot specific version. So this situation should be familiar, and it’s not > really that hard to manage an environment so that your paths are set up to > resolve the correct HDA based on which shot or job you’re on. Although in my > experience, many (if not most) VFX companies involved in commercials don’t > have this mechanism in place unless they have a film department too. > > So let’s now say that all of this is done and our paths are set up to resolve > the correct HDA. We still have to have some sort of system to manage the > versions of the HDAs properly. Otherwise what’s to stop two people unlocking > the HDA at the same time and saving back over? Even if they remember to > increment the version number, it’s still not infallible. Confusion reigns! > > That means, in an ideal world, we need an SVN style version management, > sandboxing system to retrieve, test and publish the HDAs back to the correct > location on the server. I’m pretty sure that Digital Domain had something > like this, and probably aren’t unique, but that’s a tonne of work to > implement. > > > Being a bit more pragmatic and a little less OCD about it… Personally, I > would definitely recommend having all your HDAs local to the project/job. > That way, all the versions you need, are kept with your project in case you > ever need to resurrect it. It means that you don’t have to have all the > versions that ever existed of your HDA stored centrally in your HSITE > (Houdini’s Workgroup equivalent) on the server, as it would probably cause > Houdini load times to slow down. For the most part, just manually copying and > managing them by hand there will be fine. You just strike up an agreement > that the only person to modify an HDA should be the author. > > But that’s essentially why HDAs are a bit of a pain, and we didn’t even get > into discussing having HDAs within HDAs! > > In most cases, where you just want to have the ability to reuse work, > galleries and/or presets are for me the preferred option. They don’t have > versioning issues, as once you’ve instantiated the node, that’s it. There’s > no link kept with the original definition. > > Cheers, > Andy > > > > >> On 7 Apr 2017, at 18:19, Jason S <jasonsta...@gmail.com >> <mailto:jasonsta...@gmail.com>> wrote: >> >> "So now we have 'compounds' with custom port names, now how/why are we >> not seeing dozens of those everywhere?" >> >> (also with multiple nesting levels) >> >> >> On 04/07/17 13:08, Jason S wrote: >>> Hi Andy, >>> just wanted to say thanks for the example showing possibilities for port >>> names. >>> >>> And I also noticed you can also name the regular subnet port names! >>> >>> >>> <Mail Attachment.jpeg> <Mail Attachment.jpeg> >>> >>> Titles have to be short, but are more than enough to give good clues. >>> >>> Also because I think I can recall reading that paramerters inside subnets >>> involves extra compilation time? (dont know specifics) >>> >>> >>> So now we have 'compounds' with custom port names, now how/why are we not >>> seeing dozens of those everywhere? >>> >>> In the many setups I opened from either example files or from forum users >>> posting methods, >>> I haven't come across a single Vop net that had one. (or maybe I just didnt >>> notice them?) >>> >>> (always Vops making everything from scratch with factory low level nodes, >>> or wrangle code ) >>> >>> >>> There are experienced users asking if nested HDAs are possible, and >>> responses have pointed to certain factory nodes. >>> Is it common for Digital Assets to use Digital Assets? >>> <https://www.sidefx.com/forum/topic/43014/> >>> >>> While I was surprised it was even a question, and think it should be much >>> more common. >>> >>> >>> Perhaps is it in regards to saving or retrieving custom nodes ? or is >>> management difficult? >>> >>> Could what is outlined in this thread be related? >>> My Digital Assets aren't loading with the project >>> <https://www.sidefx.com/forum/topic/42113/> >>> >>> I guess what I'm wondering is -- despite libraries and HDA's -- how/why >>> isn't encapsulation and distribution more common-ground, >>> especially after how long Houdini has been around, >>> or why are we not everywhere seeing within scenes, processes made of >>> processes made by everyone? >>> >>> And in you opinion, what could be preventing that, or what could be >>> streamlined to promote that. >>> >>> Thanks!, >>> J >>> >>> >>> On 03/31/17 5:35, Andy Nicholas wrote: >>>> Hi Jason, >>>> You can explicitly define VOP inputs and outputs if you make a digital >>>> asset, but you can also do it on a regular subnetwork. You just need to >>>> use a Subnet Input VOP for the input connections, and then use a Null VOP >>>> to name the output. You can use a Parameter VOP to expose inputs in the >>>> UI. (You can also use it to define inputs by changing the drop down at the >>>> top to "Subnet Connector", but I think it's clearer to use Subnet VOPs). >>>> >>>> I've made an example for you implementing a push along normals operation >>>> and attached it to this email. See the images below too: >>>> >>>> How the Subnet looks without connections: >>>> <Mail Attachment.png> >>>> >>>> Inside the Push_VOP subnet: >>>> <Mail Attachment.png> >>>> >>>> >>>> >>>> >>>> ------ >>>> 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.
