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

nicholas pliatsikas nicholas.pliatsikas at gmail.com
Tue May 10 06:03:12 EDT 2011

As much as i would love to able to use multple defs within the same scene
file,  I totally agree that would be a nightmare to handle on productions
like ours. The number of variables to handle would be way too great to
support easily.
Nicholas Pliatsikas

On Tue, May 10, 2011 at 10:47 AM, Jeff Wagner <jeff at sidefx.com> wrote:

> 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.
> -jeff
> 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
> _______________________________________________
> 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