God yes. With bells on. If you think that Softimage is good on that front, you'll fall hopelessly in love with Houdini.
A On 22 May 2014 at 22:29 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] > <mailto:[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]> > [mailto:[email protected] > <mailto:[email protected]> ] On Behalf Of Meng-Yang Lu > Sent: Wednesday, May 21, 2014 3:37 PM > To: [email protected] <mailto:[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] > <mailto:[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 > > > > > > > > > > > > > >
