> > 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). >
if you're talking about the lines of code to get the same stuff done in Softimage or Maya, I would say it really depends on how you approach the problem. As with all things Houdini, there are multiple ways of making plug-ins/nodes with custom GUIs. You can create the whole layout dynamically (similar to using parameters and PPGLayout in Softimage), or you can manually create the layout and connect it through scripts. I tend to do everything programmatically to keep everything in one place. I've written plenty of plug-ins which provide exactly the same functionality in various DCCs including Houdini. The code for Houdini was similar in length to the others. If you're talking about general custom plug-in development, I guess the answer would be the same for any DCC that needs to be integrated in to the production pipeline. I'm assuming, for a game studio, you have very strict rules to govern where things go in the file system. Based on your previous posts on the topic (of moving away from Softimage), I think it's safe to assume you'll need to do a fair bit of custom development. > > Is there much of an SDK for writing GUI's as front ends for tool In short, yes. My personal experience with the Houdini SDK has been fantastic. I don't recall hitting a brick wall. Going off on a slight tangent, the only thing which irritated me was lack of Python support for viewport capture. However, that can be easily done through Hscript. The good news is that it will come for Python (it's in the roadmap). For GUIs, Houdini allows using native widgets or going down the PyQt path. Thankfully, there's none of that event loop issues that Softimage has when using PyQt. My personal preference is to use native widgets as they allow for a consistent UI experience. As mentioned earlier, you can create GUIs manually (drag and drop) and link them through scripting, or you can create them programmatically. Both approaches have their merits. The Houdini Python Shell is best of breed. Imagine getting a reference to an ICE node in Softimage by dragging said ICE node in to the Script Editor, this works in Houdini. Also, hurray for auto-complete virtually wherever you can write scripts. >From a pipeline integration point of view, I think the biggest mistake people make during transition is to try and find one-to-one correlation between workflows and concepts. The best you can hope for is similarity of some concepts. There are no workgroups or custom parameter sets, however, there are equivalents which work perfectly well. Some find it strange that Houdini has no default project structure, I rather like it (now). The lack of a project structure is a testament to the fact that Houdini can be integrated in to whatever structure you're using currently. Sajjad
