November 20, 2009

Maya vs Max - yet another comparison?

Oh well, now that I'm sufficiently proficient with Maya and since I've used Max since its very early versions, it's my turn for the comparison that everyone scared of flames avoid. I know blogs are biased by definition, yet for a change, I'll be as objective as I can here - 'coz I'm sure you already got your 99% of fanboy-ism and personal preference reading such comparisons :)

- Maya is a more mature platform, don't get misled from the actual Maya release date (younger than 3DSMax) 'coz it uses a shitton of code that came straight from the super-veteran Alias Power Animator.

- Generally the above means that Maya has much more legacy code that would, in theory, make it slower and harder to integrate components. The opposite is true though, for reasons quite hard to understand and probably related to its inner engineering. Max components seem to ignore each other, with rare exceptions, while Maya plugins practically become a part of the program itself.

- Feature stability vs feature creep. Maya progresses always seemed to be careful and baby steps, allegedly because many high-profile studios had their workflows tightly integrated to its solid foundations - changing and breaking their existing in-house custom tools would mean losing those clients. For the casual user that means Maya gets new features in a sensibly slower pace than Max. Even under Autodesk reign the rule still applies - Maya 2010 compared to 2009 is a good example of this, not much to write home about. Max since early years took what many call a "bloating" approach, trying to aggregate value by means of multiple features, yet newer releases never had re-factoring of the former features as a priority, meaning what was rushed in was very rarely properly implemented in later versions. Max' NURBS implementation is a great example of that, it was pretty much abandoned by Autodesk because "everyone uses Polys nowadays". Still they keep it in the software's feature list in its half-broken, hardly-usable state.

- Max takes the crown for polygon modeling. The new Graffiti engine has some very powerful features that are hard to top. If you want a standalone modeler, flow in both Modo and Silo is much superior, but notice Silo's development has pretty much halted since last year. If you want to stick with Maya for Poly modeling, by all means get the NEX plugin. It adds insane modeling power and some very needed features like selection preservation across selection modes, mirrored cuts, and so on.

- Max texturing and shading interface works but it's quite a chore to work with and very limited. That's probably one area in which even Maya detractors have to take their hats off, although it's worth mentioning that Maya's "connection" workflow, as flexible as it is, it's very hard to grasp for most people. Once you get the hang of it and starts harnessing all its flexibility, it's hard to compare to anything else in the market.

- Max has biped and physique for easy rigging, but if you want a little bit more customization for your character (really depends on the type of production) you'll want Maya. Its driven keys interface and overall excellent stability and speed of deformation makes its animation system only comparable to (and, arguably, surpassed by) Softimage/XSI in the industry.

- For built-in scenery composition and particle effects (definitely check the plugins as well), Maya has the outworld-ish Paint FX. All you need is a single dynamic stroke seeing the plants grows, branches and leaves coming out interactively as you draw, to get instantly befuddled - and addicted.

- There's renderman for Maya. Not for Max. You really have to see its per-pixel render-time subdivision engine and motion blur / Depth of Field quality (with NO impact on render times whatsoever) to understand why it's regarded as the industry's "state of the art" renderer.

For the reasons above I'm sticking to Maya for now, yet I definitely don't think twice before using Max if it's got a plugin (generally game engine exporting ones) that I definitely need. I try to keep it to a minimum though, mainly because swapping apps, by definition, *will* slow your workflow and potentially open up a can of incompatibility worms.

Just my $0.02, just make sure to try both and make your own research.

November 08, 2009

Re-topology should be a thing of the past

I'm just so permanently annoyed about this whole "topology" issue. It's like a freaking bucket of cold water when you're teaching a natural artist all about zBrush and he's almost having a turn on, then you have to explain to him that he'll eventually have to re-topologize something to get it ready for some real-time simulation like in games, or even to get the best detailing without huge slowdowns due to massive subdivision. Huge, huge turn off. There are many different techniques and softwares to alleviate the problem, but it's always there. No matter how good the software, you're still spending three or four hours of your time laying polygons on top of your high-definition mesh. And if your real-time platform (say, console hardware) target performance isn't met and you need less definition - get ready to spend an extra morning on re-meshing (or re-topologising) everything.

I think art teams currently minimize the high cost impact this has over the production and tend to accept it as something that there's no way around. I disagree. The more we need high-quality 3D content, and the tendency is that we'll need more and more of it, the steeper the cost this silly and time-expensive process will be for us.

In the future I expect we'll have two possible solutions for the problem:

- Extremely optimized automatic re-topo where you could just define the edge loop control vertexes, placed on the fly over the high-res surface, the target polygon count, and get optimal results. There are some awesome researches about that, Andrew Shpagin from 3D Coat is at the forefront of the actual implementation of these researches on his software so I keep a tight eye on his progresses. Check this link out for some amazing pics (if you're not a math-head, just ignore the equations) and a detailed description of these under-development techniques:

- Micro-polygon displacement (or render-time displacement) will become the norm and gfx cards will fully accelerate it, so that we won't have to care much if at all about the base polygon mesh - although this still will provide problems in the actual deformation/animation department, currently highly dependent of the polygon edge flow. Would probably require, in tandem, some new real-time animation technology like topological posing with masks like zBrush does.

For now we can just keep hoping that the current re-topology chore will, rather sooner than later, be a thing of the past.