Hello,


I do a Collapse Selected into Subnet.
Then I right-click and select “Create Digital Asset”
Next Operator Type properties >Parameter tab.

All works very well. The one thing I don't know is:

what's the difference between my created digital asset and an OTL?
How can I make an OTL ?


many thanks,



bernard

I try to give my answer… someone corrects me if I'm wrong.

OTL (operator type library) is a -library- which contains Operator types..
A Digital Asset is an operator type at the end…

when people post an OTL usually posts a Digital Asset containet inside a Library with just that HDA in it.. calling the HDA (or the tool the guy is posting on the board) an OTL.. which it is.. but the what made me confused first times.. was that i tought HDA where the same as OTL .. while it is not.

from my point of view.. OTL contains HDAs.


The standard Houdini OTL contains all the OPs that you get when houdini is installed.. then you can create your own OTL and save your HDA into ‘em… all togher or every HDA in its own OTL.

ok.. I’m maybe not that clear.. but I hope this helps (and this is correct at first).

cheers.

ps. now I cant resist to post my own questions about OTL and HDA…

since I'm making my first HDAs i dunno yet how to have a correct “pipeline” to build ‘em… right now i’m having a scene hip file.. with the HDA .. I save it.. and I try it in another scene… so that if there's anything i need to change/improve I switch back to the, let's call it, my_hda.hip file .. do the correction … right click.. update the HDA (cant remember the menu and dont have houdini right now here).. and get back to the other scene.. middle click on the HDA icon.. and it gets updated with the changes.

now .. is that a way to keep a “editable and master” version of an HDA or I'm doing totally wrong?…

I ask this… cause I'll shortly need to make some HDA… and I dunno yet how to menage OTLs, versions, changes…. and get scenes which uses such HDA.. updated automatically.


thanks a lot for any hints. cheers.

When I develop an HDA, I only keep the hip file around if it takes longer than a, say a minute to recreate the context to properly test the custom operator (HDA). Once you save the HDA in an otl file on disk, you are now referencing the node from disk. This means that the hip file is no longer necessary to keep the .otl and the HDA around. Just fire up a new Houdini, source in the .otl file then place the HDA and carry on.

I like this method for developint my assets (HDA's) as I work. If I place one of my custom SOPs and I need to add a feature, as the author of the tool, I will make the changes right there.

There are quite a few shops that persistently turn off the option to embed the HDA in the hip file. This is done to ensure that every one is accessing the appropriate .otl file on disk containing the proper HDA's.

The only time you have to keep the hip file is for VOP networks that are used to author a VOP HDA.

IMHO the “Embedding OTLs to Hip Files” is the single biggest cause of problems in Houdini, ever. IMHO, that option should be removed from the UI, default to “off” and only should be enable-able via the textport. Even then it should be hidden )

Also, I agree with Jeff's methodology for single users working on simple stuff, but if you have more than 1 scene using an OTL, I do not agree with this.

The problem is, you get working, you need something new in an OTL, so you make the change. This change, if made via Jeff's method, immediately affects all other .hip files that use it. How do you know that change won't break your other .hip files?? In many cases it won't, but in the few cases that it does, bang, you've just pooched your whole project.

Worse, if you don't open one of those other .hip files for a month or so, then when you do open it it doesn't work, you now waste a huge amount of time tracking down why it's broken. Most likely you forgot about the “little” change you made to your OTL a month ago and any time you saved earlier is now more than lost.

I personally keep a .hip file for each and every OTL that I make, (well, sometimes one .hip file will have a few OTLs being created in it because they work together) and I have a “gate” system that prevents immediate changes to OTLs. I have to conciously copy over an OTL to the “job” that affects every .hip file in my project, and when I do copy it over, I am forced to make notes about what I changed, and all the older OTL files are backed up with the date of the changes and notes. If something breaks, I can immediately back out to the older one.

Admittedly, this is overkill for a single user working on a single .hip file, but I have close to 100 shots (i.e. hip files) on my project )

As an aside, the pipeline that I wrote for all this is something I'm hoping to make public. It even works on Windows, though you'll need Cygwin. )

Cheers,

Peter B

pbowmar
I personally keep a .hip file for each and every OTL that I make, (well, sometimes one .hip file will have a few OTLs being created in it because they work together) and I have a “gate” system that prevents immediate changes to OTLs. I have to conciously copy over an OTL to the “job” that affects every .hip file in my project, and when I do copy it over, I am forced to make notes about what I changed, and all the older OTL files are backed up with the date of the changes and notes. If something breaks, I can immediately back out to the older one.

I kinda do the same but I also store my hips and otls in my subversion tree. To me working in houdini is like visual programming, and I store it as I would any other source code. I should clarify that I don't store all of my hips in the tree, only hips that are used to develop an otl. Hip files for shots go into the usual JOB database.

I always have my master hips/otls in the development tree and have to actively make the decision to deploy the otl. For our purposes, it prevents silly mistakes on my end where I could possibly break a production scene.

Cheers,

/Rick

pbowmar
This change, if made via Jeff's method, immediately affects all other .hip files that use it. How do you know that change won't break your other .hip files?? In many cases it won't, but in the few cases that it does, bang, you've just pooched your whole project.

Yes, you got me. I over-simplified my workflow. Defer to Peter.

pbowmar
I personally keep a .hip file for each and every OTL that I make, (well, sometimes one .hip file will have a few OTLs being created in it because they work together) and I have a “gate” system that prevents immediate changes to OTLs. I have to conciously copy over an OTL to the “job” that affects every .hip file in my project, and when I do copy it over, I am forced to make notes about what I changed, and all the older OTL files are backed up with the date of the changes and notes. If something breaks, I can immediately back out to the older one.

A very important but subtle observation from the above paragraph: You are versioning the .otl file and NOT the actual name of the HDA operator contained in the node. Correct?

Yet another reason to get this HDA vs. OTL thing correctly. Good question Bernard.

pbowmar
As an aside, the pipeline that I wrote for all this is something I'm hoping to make public. It even works on Windows, though you'll need Cygwin.

I'll be looking out for it. Javascript?

pbowmar
IMHO the “Embedding OTLs to Hip Files” is the single biggest cause of problems in Houdini, ever. IMHO, that option should be removed from the UI, default to “off” and only should be enable-able via the textport. Even then it should be hidden

We don't embed otls in hip files either but the reason I turn it off is just so the hips files don't get big and take ages to open and save. I thought the reason the embedding was there was to avoid the exact problem you describe. If you make a change to one otl that breaks another file that other file will have a valid copy of the otl still embedded in it and you can just switch over to using that version instead. Is that not the case in practise then? You've obviuosly been burned by this so i'm interested in the how's and why's, just in case I decide it's a good idea to turn embedding back on.

Hi Simon,
Mostly it's because of the way I like OTLs to get found in the path. I don't use “Most Recent Date” but rely on the HOUDINI_PATH. If you make sure “Give Pref to Embedded” is off, then theoretically having embedded OTLs isn't so much of a problem but I've been burned regardless )
The problem is, having the embedded OTL as a “fallback” can mask problems that you don't discover until much later. For example You expect your OTLs to be found from HOUDINI_PATH but you start a new scene and HOUDINI_PATH wasn't set up correctly, or something like that. However, because of the embedded OTL your .hip file appears to load and work correctly. You work like this for a while. Then you make a change to the OTL that you thought was being used in HOUDINI_PATH and think that everything will update. But, it doesn't, because the embedded OTL is being used. Suddenly, everything doesn't work and tracking it down is a serious pain in the ass.
I much prefer having the load of the .hip file fail immediately. The problem is discovered immediately and dealt with immediately.
As an aside, I wish the error reporting for failed OTL loads was much better. A common problem I have is that a “big” OTL like a character contains a lot of little OTLs like textures etc. WHen I “Match Current Definition” and there is a missing OTL contained within, I get a red flag (sometimes) and the OTL won't lock but it doesn't tell me what's missing (

Cheers,

Peter B

It's a complex issue, so far we haven't had any serious “burnings” here. I think knowing all the potential pitfalls for a certain way of working is very useful though so thanks for the feedback. I haven't checked the help but I reckon a little list of possible modes of practise and the various pros and cons wouldn't go amiss. cheers