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 > > > >
