[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.
Cheers
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