Python scrip to replacing assets with new namespace versions

[hopbin9]

Hi all,

So I have been working on getting xTools to switch over to the new namespace feature in H12 for naming assets.

I ran into the problem that a lot of my assets were nested, and renaming an asset means that there were places the old name was still referenced.

As far as I'm aware, and confirmed by someone at Sidefx, there isn't a way to update nested assets.

So I wrote a little shelf tool that basically, copies all the parameters from one node over to the a new node that uses the new name.

Here's the script.

# Get the currently selected node.
nodes = hou.selectedNodes()
if len(nodes) == 1:
 # Prompt for the replacement
 value = hou.ui.readInput("New asset name",('OK','Cancel'))
 if value[0] == 0:
 typename = value[1]
 src = nodes[0]
 # create the new node and give it the old name
 hou_node = src.parent().createNode(typename,src.name()+"_new")
 hou_node.setPosition(src.position())
 # copy the parameters over
 for p in src.parms():
 try:
 exec(p.asCode())
 except Exception:
 print p.asCode()
 print "There was an error, this parameter not set"
 pass
else:
 hou.ui.displayMessage("Select only one node")

EDIT: Updated the script to handle exceptions setting the parameter on the target node.

EDIT: Now the new node as "_new" appended to it's name. So that expressions are not broken when old node is deleted, and new one is renamed to match old name.

So here's the use case scenario for the script.

You have an asset from H11 that has an operator type name of "xbend". You then open the operator type manager and copy that asset to a new one called "xtools::xbend::1.0", and then you delete the old "xbend" definition from the OTL file.

Now when you open a HIP file or use another asset that references "xbend". You will get an asset definition error, and the old xbend asset becomes an embedded asset. Go find the instance of the old asset, select it in the network view and then run the above shelf script. It'll prompt you for the new asset name, so enter "xtools::xbend::1.0" and it will create a new instance of that asset with all the parameters copied over from the old one. You just have to manually bring over all the inputs/outputs for that node, and now the HIP file is using the new definition that supports versions

I tried to write something that would also handle the node connections, but sadly there isn't good support for this in the Python API for subnets. I should submit a RFE for getting details about a nodes input when it comes from an unconnected subnet input, cause right now the input description is missing.

BE SURE TO LIKE XTOOLS ON FACEBOOK! JUST A FEW MORE TO HIT 100 LIKES!

Edited July 26, 2012 by hopbin9

[magneto]

Nice tool. Where is this new namespace and version parameters located in the UI?

[hopbin9]

Nice tool. Where is this new namespace and version parameters located in the UI?

They didn't really change anything in the UI. It's just a new naming convention for assets that allows you to version assets. (not to be confused with the old version parameter in the type properties window).

Digital asset namespaces and versions

I have yet to experiment with updating assets that have a version number. From what I can tell Houdini will use the asset with the latest version, but it's now possible to package multiple versions of an asset into an OTL file. This way, you can make modifications to an asset under a new version without breaking compatibility with HIP files using the older version. That's good news for me, cause there are several assets that I'd like to rewrite and now don't have to change their name. I'll just have two versions in the OTL for that asset.

[magneto]

Thanks hopbin, that's a cool feature. So to convert, can one also use the "Duplicate Asset" function and change the name there? That should also save a lot of manual work

[hopbin9]

Thanks hopbin, that's a cool feature. So to convert, can one also use the "Duplicate Asset" function and change the name there? That should also save a lot of manual work

The only difference between the duplicate and copy method is the target OTL file. When you select duplicate, then Houdini assumes that you want to place the copied asset into the same OTL the original came from. I've found no difference in my experiments between duplicate and copy. If you have a HIP file open that uses the asset, and you duplicate it then the HIP file will still be using the original and not the new copy. So it doesn't seem to do what the UI says it does.

If you don't have to worry about updating HIP files or nested assets, then you don't need to use the above script. Just duplicate and rename.

You will have to change all opdef references to the following pattern. For example, to reference an extra file as an icon

opdef:namespace::Object/assetname::1.0?extra-file.png

So I use opdef:xstudio::Object/xbox::1.0?box-closed-32.png for example in xStudio

Edited July 26, 2012 by hopbin9

[magneto]

Thanks hopbin. Btw have you seen the qlib library? I downloaded their zip but all their files seem scattered, i.e. no OTLs to be found.

I wonder if this is a different convention all together?

For your xtools, you will have 1 OTL per asset? How is it gonna work if I want to download all your assets? Seems like it's gonna be daunting to download them all and install them at Houdini startup.

[hopbin9]

Thanks hopbin. Btw have you seen the qlib library? I downloaded their zip but all their files seem scattered, i.e. no OTLs to be found.

qLib is a great open source asset library. They are using github, so the OTLs are decompiled into ASCII files and submitted to revision control that way. To do that, they use the "hotl" command using the Houdini command line prompt (it's in the start menu on Windows). Type "hotl -x temp something.otl" and it'll write out the OTL expanded to ASCII in the "temp" directory.

Just learned about this today exactly.

You can download the qLib as OTLs files from their download page. You'll need something like 7-zip to open the file, which can be downloaded from here.

I wonder if this is a different convention all together?

Yes, this is a different way of working with OTL files. I think there are pros/cons cause the OTL files that are assembled back together from ASCII files are not exactly the same as the originals.

For your xtools, you will have 1 OTL per asset? How is it gonna work if I want to download all your assets? Seems like it's gonna be daunting to download them all and install them at Houdini startup.

Yea, that would be very difficult if I did it that way. I will likely just release a single OTL file.

[magneto]

Thanks hopbin, that's pretty slick command. How did you find out that the assembled OTLs from ASCII files are different? If so, do you lose any important data? I imagine this sort of loss would occur only once I guess.

An interesting workflow for sure

[hopbin9]

Thanks hopbin, that's pretty slick command. How did you find out that the assembled OTLs from ASCII files are different? If so, do you lose any important data? I imagine this sort of loss would occur only once I guess.

No, there is no loss and nothing wrong with the generated OTL. I think it's just a matter of purest thinking that the OTL source should be the same as the OTL build.

While I've looked at the ASCII files. I don't see much advantage as a workflow in maintaining an ASCII state. Houdini isn't able to load the assets in that form so it's at best a temporary in between state. While having ASCII allows you to use text based repositories, and perform differences to see what changed. I doubt that a text merge of changes from two people would be successful. Making branching and merging in a repo impossible or at best less practical then working off the trunk.

We use SVN (kind of like Git) to store xTools in a version controlled repo. My tactic is to place each asset into individual OTL files following a naming convention for the files. This allows multiple people to make changes to xTools with less chance on making changes to the same asset. You still need to communicate with people to ensure collision doesn't happen. For the release, I'll just merge all the OTLs into a single file.

You can tell Houdini to scan a folder and load all the OTLs it finds there on startup. So it's not that hard to work with.

[magneto]

I agree with you. This actually made me curious. When you change a child asset that's used in other assets, if you change the child drastically, right now you have to update each asset that uses the child asset manually, right? That's what I remember happening, but maybe the namespaces will fix this?

Also how do you tell Houdini to scan a folder for OTLs? I only know to copy my OTL files into the user/otls folder that Houdini knows but I know it's not ideal.

[hopbin9]

I agree with you. This actually made me curious. When you change a child asset that's used in other assets, if you change the child drastically, right now you have to update each asset that uses the child asset manually, right? That's what I remember happening, but maybe the namespaces will fix this?

Namespaces allow two or more assets to have the same name as long as they have different namespaces. For example; In H11 I could never call an asset "camera", but how I can call it "xtools::camera::1.0" cause xTools make's it unique.

As for nested assets, my understand is (correct me if I'm wrong), if you have an asset called "xtools::magneto::1.0" that is used by a bunch of particle assets then you can make changes to that asset as long as you know the changes won't break anything, but let's say you want to make major changes, then you would copy that asset to "xtools:magneto::2.0". Now the particle assets would still be referencing the old "xtools::magneto::1.0" asset that is still in the OTL, but when a user selects "magneto" from the Tab menu. Houdini will only show the latest version. So when you drop "magneto" in the network it'll drop version 2.0.

That way, new instances are always the latest version. As far as updating older versions to the new version I haven't yet figured that out.

Also how do you tell Houdini to scan a folder for OTLs? I only know to copy my OTL files into the user/otls folder that Houdini knows but I know it's not ideal.

Here are some instructions I was working on for xTools.

xTools Shelf Installation

-------------------------

The following are instructions for Windows.

There are two ways to install shelf tools in Houdini.

1) Copy the files to your home directory for Houdini. On Windows this is located in "My Documents\houdini12.0"

- Move the *.shelf files to $HOUDINI\toolbar folder.

- Move the *.png files to the $HOUDINI\config\Icons folder.

2) Place xTools in it's own folder and have Houdini scan that directory, by adding the path to system variables. The follow assumes xTools was unzipped to c:\xtools

- HOUDINI_OTLSCAN_PATH = "@\otls;c:\xtools"

- HOUDINI_TOOLBAR_PATH = "@\toolbar;c:\xtools\toolbar"

- HOUDINI_UI_ICON_PATH = "@\icons;c:\xtools\toolbar"

Instructions to set the above paths for Windows 7

- click on Start

- right click on "Computer"

- select "Properties" from the menu

- click "Advanced system settings" from the sidebar menu

- click the "Environment Variables..." button

- Add the above variables to the user varaibles list.

3) Start Houdini, and the new shelf should be availible to install. Click the "+" icon on the shelf bar, and select "xTools" from the shelfs submenu. If all works, you should see a new tab called xTools with tools that have icons.

[magneto]

Thanks hopbin, just had a chance to try this and I think I am doing it wrong. Houdini gives me "bad operator type when binding handles" error at startup.

Nevermind I got it to work. I was missing the default paths apparently

Edited July 31, 2012 by magneto