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 20, 2009
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: http://www.graphics.rwth-aachen.de/uploads...siggraph_01.pdf
- 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.
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: http://www.graphics.rwth-aachen.de/uploads...siggraph_01.pdf
- 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.
September 13, 2009
The dying RTS genre
With all the buzz about Starcraft2 and the news of the latest (last?) Command and Conquer not being a pure RTS, I think I have to give a few sore words for the imminent (give it or take a few years) death of a great and once popular genre.
I won't talk about all the most recent cases of modest success (Supreme Commander, Company of Heroes) 'coz that would take pages, yet I'll focus on the few latest EA LA games. Many complained that C&C3 and the more recent RA3 construction didn't use a blizzard-like builder system - that was also employed for EA's own franchise spinoff C&C Generals - yet the failure of these games construction models had nothing to do with the MCV model itself - it's with the mutated "MCVA" (read MCV Aberration) that was implemented. Insta-deployable defenses on a "free" secondary tab? Cheap "cranes"? Both were extremely bad moves that removed critical - and tough - decisions that made the MCV gameplay fun. I won't develop the matter, but if you played RA2 or TS paying the least of attention to the play mechanics you'll easily understand what I mean. The "mutant MCV" model is so bad that no amount of balance, support or economy can fix it - believe me, we've tried hard for the CnCLab mod but like AGMLauncher from Gamereplays.org use to say it was "conceptually flawed". I won't even start on the ridiculously low build times, that inevitably led to an uncontrollable and irrational mass of units.
I know how things got to this point from an insider point of view (I was inside EA LA at the time, as part of the C&C3's community test team) and it's not as if we testers didn't put our words against most of these moves. Nevertheless all I can say about it is that nowadays design caters for marketing purposes, not for design purity or fun factor in itself. Which's a big shame, we might all stick to playing older RTS games 'coz while the industry continues to follow these "18-mins matches" and "Fast and fluid" mantras we'll keep seeing failure after failure in terms of fun factor, never mind moving the genre forward.
If the gaming market is an ecosystem, we'll probably witness RTS as an extinct genre simply for not being slim and fit enough for the new times. And no, I don't think SC2 will make this hugely different for its RTS mode itself, although it's already safe for it's outstanding moddability. Like in Warcraft3, after the "novelty" of the RTS mode fades out, mods will save the day.
Personally I'm definitely glad to see EA moving C&C away from the RTS mold, it's their best chance of at least making a real fun game while pleasing the marketing gurus - and the modern "casualized" market itself.
I won't talk about all the most recent cases of modest success (Supreme Commander, Company of Heroes) 'coz that would take pages, yet I'll focus on the few latest EA LA games. Many complained that C&C3 and the more recent RA3 construction didn't use a blizzard-like builder system - that was also employed for EA's own franchise spinoff C&C Generals - yet the failure of these games construction models had nothing to do with the MCV model itself - it's with the mutated "MCVA" (read MCV Aberration) that was implemented. Insta-deployable defenses on a "free" secondary tab? Cheap "cranes"? Both were extremely bad moves that removed critical - and tough - decisions that made the MCV gameplay fun. I won't develop the matter, but if you played RA2 or TS paying the least of attention to the play mechanics you'll easily understand what I mean. The "mutant MCV" model is so bad that no amount of balance, support or economy can fix it - believe me, we've tried hard for the CnCLab mod but like AGMLauncher from Gamereplays.org use to say it was "conceptually flawed". I won't even start on the ridiculously low build times, that inevitably led to an uncontrollable and irrational mass of units.
I know how things got to this point from an insider point of view (I was inside EA LA at the time, as part of the C&C3's community test team) and it's not as if we testers didn't put our words against most of these moves. Nevertheless all I can say about it is that nowadays design caters for marketing purposes, not for design purity or fun factor in itself. Which's a big shame, we might all stick to playing older RTS games 'coz while the industry continues to follow these "18-mins matches" and "Fast and fluid" mantras we'll keep seeing failure after failure in terms of fun factor, never mind moving the genre forward.
If the gaming market is an ecosystem, we'll probably witness RTS as an extinct genre simply for not being slim and fit enough for the new times. And no, I don't think SC2 will make this hugely different for its RTS mode itself, although it's already safe for it's outstanding moddability. Like in Warcraft3, after the "novelty" of the RTS mode fades out, mods will save the day.
Personally I'm definitely glad to see EA moving C&C away from the RTS mold, it's their best chance of at least making a real fun game while pleasing the marketing gurus - and the modern "casualized" market itself.
August 20, 2009
Emergent Game Design still emerging?
Almost a decade has passed since "emergent game design" showed up as a new buzzword in the game industry. Basically who could pull it off was pro, the rest was rubbish. Curiously, "emergence" in games in not ten-years old, it's actually something that's been around since the very early gaming days. It's basically something that occurs naturally, as long as you give the players diverse and natural tools to mix, match and discover new mechanics, be they intended by design or not. That last part doesn't really matter 'coz what gives players pleasure is the learning experience itself, not knowing if what just happened was intended or not. At least not primarily.
The thing is that Players are inventive by their own nature, the simplest challenge makes them think about ways to pull things off easier and faster - and that's where emergence is born from, not at the cold lines of code. So what's been missing is the "diverse and natural tools" part that I've mentioned before. By "natural" I actually mean stuff that work as expected. There's a sad trend of getting gameplay so meticulously under control and plastered that you see large boulders hitting soldiers right on top of their heads and not harming them, just to theoretically avoid "frustration" in a couple whining players that would just learn to place their units away from their catapults' target otherwise. But nah, let's waste them and spoon feed them a "fix" which will just make the game shallower and move it one step away from the much-needed suspension of disbelief. That is probably a dire result of game designers getting less and less secure about their own mechanical designs due to the complexity of modern games, where their ideas rarely get through to the final format as intended.
As for the "diverse" part, that is in fact the gravest point. It's easier and safer to have all enemies, for instance, share the same attributes and functionalities and tweak their values. Yet it'll sure-shot make the game incredibly boring. To add insult to injury, there's the darned massive multiplayer online (MMO) syndrome which has plagued the game industry. It's a suicidal, lemmings-like march of formerly solid companies heading towards self destruction - thinking they'll become Blizzard-mega-rich. Fact is, that MMO games has led more companies to the brink of bankruptcy and closure - and investors at the brink of insanity - than any other game genre in history. Obviously if you want to make massive content to provide for a semi-infinite amount of play time, you're bound to what I call "statistical boredom". How in heck has this contaminated regular games is hard to swallow though. I won't even get started on why on earth does a supposedly primarily multiplayer genre needs so much focus and effort on single player missions and content.
Back to the point, this lack of different functionalities or features for different units were well justified back when making 3D games was extremely hard and cumbersome. Nevertheless, nowadays the odds are completely reversed. Making high-end 3D art is way, way more expensive and time-costly than adding a few new functionalities to the same unit, made extremely trivial by modern and low-cost engines like Unity 3D. Yet spamming new 3D art with the same functionality of all else that the player has already seen results in a much shallower game, and less / short-lived fun factor.
When will designers get a clue and wake up to the new times? In large game studios that should probably start by the producers and game directors, since they're the ones deciding the directions. Since most of these large-format studios are obsolete, dinosaur beasts acting like slow-turning titanics heading to their respective icebergs, where's hope? Apparently in the smaller, agile studios that are popping up, empowered by a fresh vision and no strings attached.
Let them lead the way to better, deeper games, and shall emergence be rediscovered.
Recommended reading: http://www.planetdeusex.com/witchboy/GDC04_Emergence/sld001.htm
The thing is that Players are inventive by their own nature, the simplest challenge makes them think about ways to pull things off easier and faster - and that's where emergence is born from, not at the cold lines of code. So what's been missing is the "diverse and natural tools" part that I've mentioned before. By "natural" I actually mean stuff that work as expected. There's a sad trend of getting gameplay so meticulously under control and plastered that you see large boulders hitting soldiers right on top of their heads and not harming them, just to theoretically avoid "frustration" in a couple whining players that would just learn to place their units away from their catapults' target otherwise. But nah, let's waste them and spoon feed them a "fix" which will just make the game shallower and move it one step away from the much-needed suspension of disbelief. That is probably a dire result of game designers getting less and less secure about their own mechanical designs due to the complexity of modern games, where their ideas rarely get through to the final format as intended.
As for the "diverse" part, that is in fact the gravest point. It's easier and safer to have all enemies, for instance, share the same attributes and functionalities and tweak their values. Yet it'll sure-shot make the game incredibly boring. To add insult to injury, there's the darned massive multiplayer online (MMO) syndrome which has plagued the game industry. It's a suicidal, lemmings-like march of formerly solid companies heading towards self destruction - thinking they'll become Blizzard-mega-rich. Fact is, that MMO games has led more companies to the brink of bankruptcy and closure - and investors at the brink of insanity - than any other game genre in history. Obviously if you want to make massive content to provide for a semi-infinite amount of play time, you're bound to what I call "statistical boredom". How in heck has this contaminated regular games is hard to swallow though. I won't even get started on why on earth does a supposedly primarily multiplayer genre needs so much focus and effort on single player missions and content.
Back to the point, this lack of different functionalities or features for different units were well justified back when making 3D games was extremely hard and cumbersome. Nevertheless, nowadays the odds are completely reversed. Making high-end 3D art is way, way more expensive and time-costly than adding a few new functionalities to the same unit, made extremely trivial by modern and low-cost engines like Unity 3D. Yet spamming new 3D art with the same functionality of all else that the player has already seen results in a much shallower game, and less / short-lived fun factor.
When will designers get a clue and wake up to the new times? In large game studios that should probably start by the producers and game directors, since they're the ones deciding the directions. Since most of these large-format studios are obsolete, dinosaur beasts acting like slow-turning titanics heading to their respective icebergs, where's hope? Apparently in the smaller, agile studios that are popping up, empowered by a fresh vision and no strings attached.
Let them lead the way to better, deeper games, and shall emergence be rediscovered.
Recommended reading: http://www.planetdeusex.com/witchboy/GDC04_Emergence/sld001.htm
August 08, 2009
Lightwave to MotionBuilder
If you've ever done anything related to character animation for real time applications - most noticeably games - you already know that these real-time engines don't have any time to spare to "fix" our 3D characters bone influence weightmaps like in most non-realtime 3D applications rendering. That basically means you have to resort to "explicit" maps which have absolutely zero tolerance for things like vertices with over 100% or under 100%. So if you have, say, forearm and arm bones influencing the same elbow vertices, you'd better make sure that both sum up to 100% - eg. 60+40 or 50+50 - or else all sorts of weird distortions happen. In Lightwave 3D you can simulate the effect of explicit maps by toggling the "Use Weightmaps only" bone properties option and making sure "Normalize weights" is off.
Now, let's say you want to spare yourself from the troubles and complexities of setting up a full rig - which's a digital puppet armature with all the wiring, knobs and levers set up properly for ease of animation - yourself. The best standalone option out there is Motion Builder, owned by the giant Autodesk. Once you experiment its power, it's hard to look back. It's safe to say that Lightwave's powerful IK booster comes close in terms of posing power and might even surpass the market leader in terms of flexibility, but the fact is that for professional high-end animation, you need live IK, physics and ragdoll effects, and that Motion Builder delivers in spades.
The problem is, Motion Builder uses explicit weightmaps, just like most 3D applications, so trying to import your Lightwave models with bones directly into it will surely result in some of the weirdest deformations you'll ever see. So you go back to Lightwave and painstakingly have to set up the weight maps one by one, using the same naming conventions motion builder uses to make its "characterize" process seamless. Not to mention having to set up that complex hierarchy of about 90 bones and later tying it all up together. And why don't we have a mirror weights option, you don't mean I'll have to re-do everything finger part by finger part in the other hand do ya?? Ouch..
Fear not though, Lightwave's community to the rescue! First, since this is the most helpful 3D app community in existence, I want to give back I little so I'm giving away my meticulously setup rig model with all skelegons properly named and ready for joint conversion. It's in the bottom of this text just like all other links. To use it, open it in Modeler, then tweak the vertices to comply to your specific model, you can refer to any Motion Builder tutorial model to check where each joint is supposed to be. To convert the skelegons to joints in Layout (instead of regular z-bones, remember joints is what Maya and Motion Builder uses) I strongly recommend using Adam Redwood's script, to make sure the joints are named correctly in Layout.
So now the big problem is mapping those weights right? Okay, first let's explore our options. If you have the bucks, you can try using the default Lightwave bone options (strength and falloff type) to make sure no bones are affecting areas they shouldn't, then use Okino's Polytrans software to generate an explicitly-weighted model. Haven't tried it myself yet, but according to the company's info in their website it'll joyfully create all weight maps for you.
As for the second option, you can manually set up the weights using symmetry for things like the fingers, copying (duplicating) the map, rename it (say, left to right), then clean up the vertexes from the non-desired side in both maps. Zzzzzz. The apex of needless repetitiveness - read, tedium - in my book.
Third option is what I'm here to talk about. First set up parts for each weightmap you want for just the center and left side of your model, I suggest hiding each part as you create it to avoid overlapping regions. Then use Trueart's handy parts to weight plugin to convert these parts to weightmaps. Now, manually optimize your wmaps for best deformation - you know, things like lowering the shoulder influence under the arm - not bothering about compensating the adjoining bones as one regularly would. To smooth out large chunks automatically, use the wmapblur plugin.
Now you've got a full half of your character done and you want to mirror these weights to the other half. You may be tempted to use the ancient YO_mirrorweights plugin, in my tests it did work on LW 6.5 but it crashed on 7.5, actually it won't even show up on 9.6 as available after you install it. As hard as it is to find and run, if you have access to a 6.5 installation by all means use it, it's a great option. Kung Fu Tools is supposed to be even better, but I couldn't find it anywhere - if you still have it lurking in your hard drive, please share it in the Lightwave forums.
"MaDDoX, I don't have LW 6.5, am I doomed?". Not at all, because Sir Timothy Albee kindly shared with us one amazing tool called BG Morph-and-Weight Copy. What this little gem of a tool allows for is copying weightmaps from completely distinct shapes. Although its intended use is for just slightly different shapes, in fact all you have to do is create a morph map for the target character, tweak it to roughly conform to the original (properly weightmapped) character and apply the script with a sizeable threshold. What that technique allows for is that once you have a good-behaving model of a certain style, say, a biped, you should never have to spend time creating its weights again, just tweaking it to compensate for different proportions.
Anyways, the point here is mirroring the weightmaps, how can BG weight copy help us? Here's a technique that I figured out that solves just that:
1. Copy your object and paste it into a new object
2. Use FI's Move VMaps plugin to rename all your weight maps from "Left" to "Right"
3. You'll now stretch your object horizontally, set -100 to the X axis in the numeric window and apply. Flipping the normals after that is optional since we'll just use it to copy the vertex maps from
4. Delete the non-symmetrical weightmaps, like Spine and Neck
5. Copy the mirrored object and paste it into a background layer of your original object
6. Set the FG and BG properly and run Copy BG Weight.
Presto! After some moments you'll have your mirrored weights. If you run into any "overlapping vertices" error, simply select any of your model polygons, perform a 'select connected' and cut/paste it to another BG layer.
Finally, all that's left to do is to run normalize weights, using the other script by Timothy Albee, that'll adjust your weights proportionally to their original values but make sure all vertices weights sum to 100%. Done, you'll now have a complete motion builder compatible character ready to FBX export. So here's my little gift setup/mini-tutorial to you guys, I hope you put it to good - and profitable ;) - use. Have fun!
MB-compatible Skelegons Rig: http://www.gamereplays.org/community/index.php?act=Attach&type=post&id=503607
Skelegons to Joints: http://www.newtek.com/forums/showthread.php?t=88466
Parts to Weight: http://www.trueart.pl/?URIType=Directory&URI=Products/Plug-Ins/PartsToWeights
YO_MirrorWeights:
FI's Weightmap Blur: http://www.lwplugindb.com/Plugin.aspx?id=b1110c24
TA BG Weight Copy and Normalize Weights: http://loupguru.com/store/index.php?main_page=index&cPath=1_11
Now, let's say you want to spare yourself from the troubles and complexities of setting up a full rig - which's a digital puppet armature with all the wiring, knobs and levers set up properly for ease of animation - yourself. The best standalone option out there is Motion Builder, owned by the giant Autodesk. Once you experiment its power, it's hard to look back. It's safe to say that Lightwave's powerful IK booster comes close in terms of posing power and might even surpass the market leader in terms of flexibility, but the fact is that for professional high-end animation, you need live IK, physics and ragdoll effects, and that Motion Builder delivers in spades.
The problem is, Motion Builder uses explicit weightmaps, just like most 3D applications, so trying to import your Lightwave models with bones directly into it will surely result in some of the weirdest deformations you'll ever see. So you go back to Lightwave and painstakingly have to set up the weight maps one by one, using the same naming conventions motion builder uses to make its "characterize" process seamless. Not to mention having to set up that complex hierarchy of about 90 bones and later tying it all up together. And why don't we have a mirror weights option, you don't mean I'll have to re-do everything finger part by finger part in the other hand do ya?? Ouch..
Fear not though, Lightwave's community to the rescue! First, since this is the most helpful 3D app community in existence, I want to give back I little so I'm giving away my meticulously setup rig model with all skelegons properly named and ready for joint conversion. It's in the bottom of this text just like all other links. To use it, open it in Modeler, then tweak the vertices to comply to your specific model, you can refer to any Motion Builder tutorial model to check where each joint is supposed to be. To convert the skelegons to joints in Layout (instead of regular z-bones, remember joints is what Maya and Motion Builder uses) I strongly recommend using Adam Redwood's script, to make sure the joints are named correctly in Layout.
So now the big problem is mapping those weights right? Okay, first let's explore our options. If you have the bucks, you can try using the default Lightwave bone options (strength and falloff type) to make sure no bones are affecting areas they shouldn't, then use Okino's Polytrans software to generate an explicitly-weighted model. Haven't tried it myself yet, but according to the company's info in their website it'll joyfully create all weight maps for you.
As for the second option, you can manually set up the weights using symmetry for things like the fingers, copying (duplicating) the map, rename it (say, left to right), then clean up the vertexes from the non-desired side in both maps. Zzzzzz. The apex of needless repetitiveness - read, tedium - in my book.
Third option is what I'm here to talk about. First set up parts for each weightmap you want for just the center and left side of your model, I suggest hiding each part as you create it to avoid overlapping regions. Then use Trueart's handy parts to weight plugin to convert these parts to weightmaps. Now, manually optimize your wmaps for best deformation - you know, things like lowering the shoulder influence under the arm - not bothering about compensating the adjoining bones as one regularly would. To smooth out large chunks automatically, use the wmapblur plugin.
Now you've got a full half of your character done and you want to mirror these weights to the other half. You may be tempted to use the ancient YO_mirrorweights plugin, in my tests it did work on LW 6.5 but it crashed on 7.5, actually it won't even show up on 9.6 as available after you install it. As hard as it is to find and run, if you have access to a 6.5 installation by all means use it, it's a great option. Kung Fu Tools is supposed to be even better, but I couldn't find it anywhere - if you still have it lurking in your hard drive, please share it in the Lightwave forums.
"MaDDoX, I don't have LW 6.5, am I doomed?". Not at all, because Sir Timothy Albee kindly shared with us one amazing tool called BG Morph-and-Weight Copy. What this little gem of a tool allows for is copying weightmaps from completely distinct shapes. Although its intended use is for just slightly different shapes, in fact all you have to do is create a morph map for the target character, tweak it to roughly conform to the original (properly weightmapped) character and apply the script with a sizeable threshold. What that technique allows for is that once you have a good-behaving model of a certain style, say, a biped, you should never have to spend time creating its weights again, just tweaking it to compensate for different proportions.
Anyways, the point here is mirroring the weightmaps, how can BG weight copy help us? Here's a technique that I figured out that solves just that:
1. Copy your object and paste it into a new object
2. Use FI's Move VMaps plugin to rename all your weight maps from "Left" to "Right"
3. You'll now stretch your object horizontally, set -100 to the X axis in the numeric window and apply. Flipping the normals after that is optional since we'll just use it to copy the vertex maps from
4. Delete the non-symmetrical weightmaps, like Spine and Neck
5. Copy the mirrored object and paste it into a background layer of your original object
6. Set the FG and BG properly and run Copy BG Weight.
Presto! After some moments you'll have your mirrored weights. If you run into any "overlapping vertices" error, simply select any of your model polygons, perform a 'select connected' and cut/paste it to another BG layer.
Finally, all that's left to do is to run normalize weights, using the other script by Timothy Albee, that'll adjust your weights proportionally to their original values but make sure all vertices weights sum to 100%. Done, you'll now have a complete motion builder compatible character ready to FBX export. So here's my little gift setup/mini-tutorial to you guys, I hope you put it to good - and profitable ;) - use. Have fun!
MB-compatible Skelegons Rig: http://www.gamereplays.org/community/index.php?act=Attach&type=post&id=503607
Skelegons to Joints: http://www.newtek.com/forums/showthread.php?t=88466
Parts to Weight: http://www.trueart.pl/?URIType=Directory&URI=Products/Plug-Ins/PartsToWeights
YO_MirrorWeights:
FI's Weightmap Blur: http://www.lwplugindb.com/Plugin.aspx?id=b1110c24
TA BG Weight Copy and Normalize Weights:
Update: Two years after writing the original article, what a nice surprise I had when I found that multiple advancements were done in that area. Lightwave 10 has a much improved export/import FBX plugin now, and the rigging master, RebelHill, got some inspiration from my researches and has developed two absolutely brilliant video tutorials explaining the arcane details that I couldn't unveil back then. If you want to go down the LW->Mobu->LW workflow, by all means check these life-saving videos:
Understanding LW and FBX
- http://www.youtube.com/watch?v=clia07kKtKs (part 1)
- http://www.youtube.com/watch?v=DLjJIaFwS4U (part 2)
July 30, 2009
Character Anim Woes
So, character animation has never been a breeze - in any format, although I'm specifically addressing 3D character anim here. Whenever a client approaches me and asks me to give life to his new puppy, the line "OMG, rigging.." immediately pops into my mind. No matter what solution or approach you use, the only sure thing is that you'll run into trouble. Fact is, no 3D application does it all as efficiently and cleanly as if you use multiple tools, but when you go down that path you inevitably add the darned "conversion" issues to your pipeline. Either your 3D applications have different conceptions about what direction the Y axis points to, or Motion Builder wants you to rotate your character 180 in the Y axis (wait, or is it Z?) - what will inevitably break your rig no matter how simple a "180 rotation" process sounds in theory.
Be it import/export conversion, rigging tools or advanced shading, high-end features are always like that. They cater for a very small share of any company's user base, and receive a proportional attention - read, investment - in terms of proper functionality and support.
Probably just how the economics dictatorship makes things go, but you know what's the most curious thing? We artists rarely account for that when we estimate our schedules, no matter how spanked we traditionally are by such processes. Go figure.
Be it import/export conversion, rigging tools or advanced shading, high-end features are always like that. They cater for a very small share of any company's user base, and receive a proportional attention - read, investment - in terms of proper functionality and support.
Probably just how the economics dictatorship makes things go, but you know what's the most curious thing? We artists rarely account for that when we estimate our schedules, no matter how spanked we traditionally are by such processes. Go figure.