[Sidefx-houdini-list] Different otl version per node instance

Jeff Wagner jeff at sidefx.com
Tue May 10 05:47:46 EDT 2011

Currently Houdini's behaviour is to have each asset defined by a single 
definition using it's name as the unique qualifier in the current 
session. There is no way to have a single one-off override for a node to 
point to a different .otl file on disk. This could get quite confusing 
in heavy production for artists?

As was mentioned by Sebastian, it is straightforward to have a new name 
for the version and point your node to that new version. With two 
definitions loaded, say "my_asset_v001" and "my_asset_v002" defined by 
my_asset_v001.otl and my_asset_v002.otl respectively, you can use the 
RMB Change Type... option on the node and choose the version you wish 
this node to use. As was mentioned also by Sebastian, you can create 
your own logic that can present the user a filtered set of operators to 
just my_asset* but RMB > Change Type works.

Btw there is an existing RFE to have Change Type work with type ahead as 
the tab menu does. If this were implemented, it would make this step 
more user friendly. All of this is script-able via Python HOM.


The current limitation is that Houdini only allows for a single 
definition for "copy"

On 11-05-10 6:12 AM, François Duchesneau wrote:
> Lots of interesting ideas so far but nobody has given an opinion on 
> why it couldn't be possible to make a new feature to allow more than 
> one version at the same time of the same otl definition.
> People from SideFx maybe could comment about it.
> François
> Dan Schneider wrote:
>> the Cpp API seems to have fairly elegant ways of dealing with old 
>> node version and converting the parms etc... when moving to a new 
>> version. I wonder if similar methodology could apply via python? Off 
>> the top of my head maybe a creation event triggers a script that 
>> looks for old versions (not current defs), extracts the changed 
>> parameters and then knows how to properly convert/munge the data to 
>> apply to new version. This would of course have to be done per HDA 
>> but id imagine for specific show/shop use it would be possible to 
>> streamline the process with a more generalized script and maybe a 
>> xml/yaml type markup for the specific case? Of, course I am just 
>> thinkning outloud and haven't actually looked at the logistics... 
>> just throwing it out there....
>> ----- Original Message ----
>> From: Antoine Durr <antoinedurr at gmail.com>
>> To: sidefx-houdini-list at sidefx.com
>> Sent: Tue, May 10, 2011 8:47:18 AM
>> Subject: Re: [Sidefx-houdini-list] Different otl version per node 
>> instance
>> Agreed.  And by way of convention, we say "if the new version  is not 
>> compatible with the old one, bump up the version number."  I've 
>> written systems where the otl itself has a major version number 
>> buried in its name, and then the CVS/Subversion/etc. system adds a 
>> minor version after it.  That way when you make simple changes, you 
>> go from 2.4 to 2.5, then to 2.6.  But now if you add something that 
>> creates a cross incompatibility, bump up the major version to 3, and 
>> restart the cvs'ing at 0.
>> Then for bonus points you modify the OPcustomize file to first ophide 
>> the old versions.  That way <tab> only lists the current one.  Then 
>> at some later point you opalias the new one to the old one and remove 
>> the old one.  That way when they load the file, the old automatically 
>> gets upgraded to the new one.
>> Fancier systems use the pipeline to redirect which version of the otl 
>> you're going to receive.  If you need both the old and the new, you 
>> "subscribe" to them both and presto, you have access to both.
>> -- Antoine
>> On May 8, 2011, at 10:13 AM, Peter Bowmar wrote:
>>> Hi Francois,
>>> We use the same thing that Sebastian is describing, only way to work 
>>> IMO :)
>>> Cheers,
>>> Peter B
>>> 2011/5/8 François Duchesneau <sidefx at trinix.ca>:
>>>> Hi Sebastian,
>>>> I must admit that logically that seems to work. I'd be a bit afraid to
>>>> introduce that into a pipeline since it breaks pretty much the 
>>>> standard way
>>>> of managing assets inside Houdini and we lose all the tools 
>>>> available to us.
>>>> Still I wonder if there's a good reason why SideFx doesn't want to 
>>>> have that
>>>> implemented the way I explained below. If people let the "Use Default
>>>> Definition" check box, then the existing way wouldn't be broken right?
>>>> François
>>>> Sebastian H. Schmidt wrote:
>>>>> Hi Francois,
>>>>> you could start to version your otls, even with the label, so 
>>>>> whenever
>>>>> you create a new version of your car, the file gets versioned
>>>>> (myCar_v002.otl) but also the asset itself gets a new name,
>>>>> myCar_v002.
>>>>> You could add some kind of pre-flight so that:
>>>>> -  hides all myCar_v00* smaller than your current version from the
>>>>> tab-menu, and
>>>>> - even creates a entry in the tab menu  so that if someone adds a
>>>>> myCar asset it will use the latest one (myCar_v002)
>>>>> - some right button magic where you give the artist the chance to see
>>>>> a list of revisions of that asset and the chance to update it
>>>>> --> so if the asset gets updated (v002-->v003) the artist uses by
>>>>> default its version, maybe the node gets flaged so the artist could
>>>>> choose wether he wants the new definition or not
>>>>> just my 5 ct.
>>>>> Seb
>>>>> 2011/5/8 François Duchesneau <sidefx at trinix.ca>:
>>>>>> Hi everybody,
>>>>>> I'm curious to get the opinion of others about something that I 
>>>>>> find more
>>>>>> like a limitation than a feature in Houdini.
>>>>>> Why aren't we able to chose per node what version of the otl it 
>>>>>> reads. I
>>>>>> mean there should have "Use Default Definition" for most of the 
>>>>>> nodes but
>>>>>> there are times when you'd like to force a node to point a specific
>>>>>> version
>>>>>> of otl without changing at the scene level. For example, I 
>>>>>> release a new
>>>>>> asset (car) that contains other custom assets (window, door). My 
>>>>>> new car
>>>>>> asset has been designed to work with a newer version of window 
>>>>>> and door
>>>>>> but
>>>>>> in the shot hip files, there is a helicopter asset that is only
>>>>>> compatible
>>>>>> with the old version of the window.
>>>>>> I know some will say, you should design your tools so they are 
>>>>>> always
>>>>>> backward compatible etc. but the production reality is that I 
>>>>>> don't want
>>>>>> to
>>>>>> think about my design for weeks. I just want to deal with Houdini 
>>>>>> assets
>>>>>> like I would for any file called in reference in Maya for example.
>>>>>> Wouldn't be great to be able to do so?
>> _______________________________________________
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>> _______________________________________________
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
> _______________________________________________
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list

More information about the Sidefx-houdini-list mailing list