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

Sean Lewkiw Sean.Lewkiw at cis-vancouver.com
Tue May 10 12:11:08 EDT 2011


I don't recall who mentioned it, but someone way back in the mists of time pointed out something that Softimage has, (some kind of digital asset like thing), where, built-in to the DA itself is a field for major, minor and patch, (where, for example, patch releases are trivial things like interface updates, new icons, etc., and higher minor and major releases might change functionality).  This way you could just increment these to suit when saving, keeping the name the same.

Then you would have prefs in Houdini:  "[Always|Never] upgrade to to latest [major|minor|patch] release" and/or "Alert user to new [major|minor|patch] release".  Then you would have a nice dialogue box with your asset and every single release from which you could easily choose.  You could even store all of these releases in a single otl file.

Sean

-----Original Message-----
From: sidefx-houdini-list-bounces at sidefx.com [mailto:sidefx-houdini-list-bounces at sidefx.com] On Behalf Of Ken Ouellette
Sent: Tuesday, May 10, 2011 6:27 AM
To: sidefx-houdini-list at sidefx.com
Subject: Re: [Sidefx-houdini-list] Different otl version per node instance

I think Jeff's comments are spot on.

I don't get to use Houdini as much, but I ate a lot of ground working with
OTLs when they first came into existence and I admit there are a few factors
that can trip you up. There is a lot of pre-planning and pre-conceiving that
has to be done to walk through usage and workflow with OTLs. But you have
one "type" you can upgrade it and point your hipfile to a newer or older
version of that "type", some of the changes that exist in your definitions
will either work with the data in your file or it won't. In some cases you
have to plan around the changes. In other cases you need to crack the OTL
open and just get it done.

I went back to your original question "I just want to deal with Houdini
assets like I would for any file called in reference in Maya for example."

It might be helpful to consider what is it about the reference that you were
hoping to get out of OTLs. It could be a usage or design consideration and
it might be mean you need to look at the design of your OTLs or what you are
doing with them. Even references will only get you so far in Maya. Reference
edits can be the death of you and even though Maya lets you do things with a
reference it doesn't mean it won't change things under the hood in the
actual maya file so it can actually do what the user has asked to do. I'm
thinking an example is applying a deformer on a shapeNode that is coming
from a reference. Reference or not, maya inserts new suffix for the node in
question and creates a new one Orig and Deform. Once you open up an OTL you
have the same problem trying to retain some of the versioning and promotion
issues from newer definitions, but it is a choice that has to be made.

Designing a structured way to branch, iterate (version up) and then
republish a type into the pipeline is a legit way to go as well.

So much fun.
-k



2011/5/10 François Duchesneau <sidefx at trinix.ca>

> 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
>
>
_______________________________________________
Sidefx-houdini-list mailing list
Sidefx-houdini-list at sidefx.com
https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list


This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.




More information about the Sidefx-houdini-list mailing list