>> 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> 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 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.
