Heh! Yeah right. Like you need me to ;)
On 22 May 2014 at 23:11 Meng-Yang Lu <ntmon...@gmail.com> wrote: > 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 <ml...@carbinestudios.com > <mailto:ml...@carbinestudios.com> > 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: softimage-boun...@listproc.autodesk.com > > <mailto:softimage-boun...@listproc.autodesk.com> > > [mailto:softimage-boun...@listproc.autodesk.com > > <mailto:softimage-boun...@listproc.autodesk.com> ] On Behalf Of Meng-Yang Lu > > Sent: Wednesday, May 21, 2014 4:18 PM > > To: softimage@listproc.autodesk.com > > <mailto:softimage@listproc.autodesk.com> > > 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 <ml...@carbinestudios.com > > <mailto:ml...@carbinestudios.com> > 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: softimage-boun...@listproc.autodesk.com > > <mailto:softimage-boun...@listproc.autodesk.com> > > [mailto:softimage-boun...@listproc.autodesk.com > > <mailto:softimage-boun...@listproc.autodesk.com> ] On Behalf Of Meng-Yang Lu > > Sent: Wednesday, May 21, 2014 3:37 PM > > To: softimage@listproc.autodesk.com > > <mailto:softimage@listproc.autodesk.com> > > 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 <ml...@carbinestudios.com > > <mailto:ml...@carbinestudios.com> > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
