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

Dan Schneider eyevex at yahoo.com
Mon May 9 19:51:49 EDT 2011


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




More information about the Sidefx-houdini-list mailing list