I'm trying to correlate the languages of both packages. Maybe Andy Nicholas can double-check my work but Houdini Attributes behave like custom data throughout all component and object levels of any asset. Groups act like clusters which you can use to apply whatever attribute (metadata) you want and impart various behaviors based on them.
As far as things being tamper proof I'm not sure. The Mr. Potatohead reference is absolutely doable and probably easier imo than Softimage. There's a whole ecosystem built around managing arbitrary data in Houdini. -Lu On Thu, May 22, 2014 at 2:29 PM, Matt Lind <[email protected]> wrote: > Replicating bullets and stuff like that is not the kind of carbon copying > we need as cloning would cause problems. Every asset needs to be unique > and trackable, so having a master mesh and running a bunch of ops to > clone/duplicate/instance is not really the target we’re aiming for. > Although that functionality is useful, it’d probably be more directed at > building parts of environments than characters or props. > > > > What we need is the ability to constrain users from going outside the > lines we’ve drawn. Imagine a yard with tall electrified fences. Users are > allowed to roam anywhere in the yard, but are not allowed outside the > fence. As we iterate on our pipeline, we push the fences further and > further out to get users more room to roam. But the constant is we need to > persist metadata on the assets and prevent that metadata from being > inadvertently modified as well as ensure the metadata is applied in such a > way it can be reliably found and relied upon to drive tools and behaviors > within the pipeline. > > > > For example. > > > > Our characters are built like Mr. Potato head dolls. They are not a > single seamless mesh. There is a base body mesh, but holes left for other > parts to plug in such as ears, faces, hair, clothing, etc… The locations > for the body parts are defined by clusters, custom properties, and other > metadata. Once the character is defined it’s placed in a referenced model > to prevent users from tampering with the metadata to ensure tools are > reliable and can find, track, and assemble the parts with other assets to > create what the artist needs to pull into a scene to do his/her work. Same > rules and generalities apply to other areas of the pipeline. Render passes > are used to allow artists to build the environment geometry once, and > redress it many times with texture and shader swaps. Since some of the > metadata describes components which customers can purchase, the assigned > IDs for the components needs to be maintained and be tamper proof. > > > > Does Houdini offer mechanisms to control assets in this fashion to ensure > data integrity year over year in a fluid pipeline? > > > > > > Matt > > > > > > > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Meng-Yang Lu > *Sent:* Wednesday, May 21, 2014 4:18 PM > *To:* [email protected] > *Subject:* Re: Houdini Weaknesses > > > > This is actually where Houdini shines. Taking something that exists and > manipulating the DATA to create something new. > > > > Say you've got characters that have like belts of ammo as an accessory. > You can create a dependency saying something like... if you choose type > bullet, it also drives the number of bullets on the belt. So if you choose > type grenade which are larger in size, that type can drive the lesser > number of grenades on the belt. Between nodes like copy/stamp and > switches, you can build these into your system. You could, if all the > assets are there, build a character creation system seen in a lot of games > if you wish. Even up to clever things like stating which type of weapon > the character is holding. Like if a weapon is two-handed by type, you > could never have a single-offhand accessory, thus never having things that > could conflict if both existed. > > > > The best way to think of Houdini is not just an FX tool. It's an > operating system that manages 3D data and does it extremely well. This is > why it takes a long time to build the setup, but the payoff is that over > time, you gain a huge advantage of creating various version of one thing as > long as you've built it into your setup. > > > > Modeling and texturing really should be done somewhere else. But once > those assets are create and you want to manipulate it, Houdini become a > really powerful ally in this case. > > > > -Lu > > > > > > > > On Wed, May 21, 2014 at 3:52 PM, Matt Lind <[email protected]> > wrote: > > That makes sense for an FX workflow as every project is essentially > unique, but in a production where you churn out a lot of carbon copies or > variations of the same content, how well does Houdini’s framework/workflows > cater to that? For example, are there mechanisms or abilities to enforce > certain ways of working? That’s probably our biggest concern as our > content has to be functional, not just look good. To be functional > requires certain elements be consistently defined on the assets and the > asset structured in particular ways. > > > > One weakness I see so far is the lack of API for hardware shader > development. GLSL is there, but it’s slow compared to straight OpenGL. I > haven’t looked very deeply, but at a quick glance I don’t see any Direct X > support. > > > > One thing that would be really useful for the transition guides is more > focus on modeling and texturing. Houdini seems to have the basic > building blocks, but the rest has to be developed/configured by the user. > > > > Matt > > > > > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Meng-Yang Lu > *Sent:* Wednesday, May 21, 2014 3:37 PM > *To:* [email protected] > *Subject:* Re: Houdini Weaknesses > > > > Yes. It's nodes and expression heavy. And for that same reason it > drastically reduces plugin development cause you're essentially programming > every time you're in the package. And just like you'd copy and paste > snippet of code, you'd do the same but with nodes of a tree. > > > > Whenever I feel like I need to do dev work in Maya which is often, I just > go to Houdini now. > > > > The UI creation is also pretty nifty. You basically have access to all > the params, sliders, and widgets you'd normally see in Houdini's default > tools. Just a matter of dragging, dropping, and organizing to your heart's > content. You can promote params from a lower level to a higher level at > anytime, exposing only what you want the artist to see. > > > > You can do error checking either through the nodes or through vops/vex. > > > > It's got one foot in as a 3D application and 2 feet in as a plug-in > development platform. Yes, 3 legged analogies are weird, just like > Houdini. But I like it now. > > > > -Lu > > > > > > > > > > On Wed, May 21, 2014 at 3:17 PM, Matt Lind <[email protected]> > wrote: > > Seems like Houdini is heavy on nodes and expressions to create your work. > > How much custom plugin development do you have to do with Houdini compared > to Softimage, Maya, etc...? Let's define a plugin as something you'd write > as a script or C++ lib that gets included in the software as a reusable > tool, perhaps providing it's own GUI front end (if applicable) and is > responsible enough to do proper error checking (as opposed to a couple line > hack script like many artists do). > > Is there much of an SDK for writing GUI's as front ends for tools? > > > Matt > > > > >
