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

Antoine Durr antoinedurr at gmail.com
Mon May 9 18:47:18 EDT 2011

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?

More information about the Sidefx-houdini-list mailing list