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

François Duchesneau sidefx at trinix.ca
Tue May 10 01:12:47 EDT 2011


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
>
>   



More information about the Sidefx-houdini-list mailing list