The MaDDoX Corner

Visual Scripting and Coding for Games

2011-04-12T12:12:00.000-07:00

Recently a new visual coding extension/component for the Interactive Content and Game Development platform Unity (my engine of choice) has been announced. It's called uScript and its promotional videos are quite enticing. I've been using Unity for years, coding some C#, and since its beta I've been using Playmaker extensively. I've also checked Antares Universe, a competing component to uScript, although not to the same extent. So I'll make a quick rundown of not only the advantages of the tool but also how I see the whole situation involving OOP/coding, visual coding and FSM editors for game development - from a designer point of view with some solid coding background. Hopefully this is an interesting and mid-ground perspective that might interest some of you.

- OOP (Object Oriented Programming). Encapsulation and Properties are great, inheritance and polymorphism suck - for designers trying to read code at least. Having to read cold lines of text is already sufficient to pull a designer's mind away from the code, now having to keep multiples text files open and hopping back-and-forth among them just to understand exactly what a piece of code is supposed to do is something that, even as someone with a degree in the area and used to OOP underlying concepts, I personally despise. If you're used to notepad or notepad++, forget it, things become extremely hard to understand and usage is very susceptible to a plethora of bugs as you struggle with function names and definitions which are "somewhere else". To properly code with OOP you're pretty much *forced* to use Visual Studio and preferably Resharper just to understand what's going on, and as much as coders tout it I still find those solutions awkward and ineffective to fully grasp the power of object orientation. I find I can fragment (factor) code chunks much more while visualizing it much better using Playmaker than with pure Visual Studio + Resharper (and/or Visual Assist X).

- Visual Coding (Kismet, Antares, uScript). First and foremost, let's get something straight: if you don't know how to create a flowchart to describe game logic you're not a real designer, you're like a writer with good ideas that don't necessarily need to be feasible. So, supposing you are a designer, what's left to do? From a designer/developer PoV, I want to be able to "transcribe" my game logic flowchart to the computer, setting up commands and parameters with drop down menus to get the right fields, instead of typing a name and doubtfully hoping it's the right property or variable. VS/Resharper already gives you that possibility, so all that's left is to know what's the correct syntax to get loops and routines working as we want. Visual Assist does have code snippets that help a lot with this. So, supposing you have the right tools and don't try using the harder OOP concepts, you can describe your logic inside Unity quite easily. That's why some people make fun of Visual Coding claiming "it's already too easy to code in Unity". What they don't realize is how easier it is to create and visualize high-level and complex logics with a visual tool, due to their frequently non-linear and parallel nature.

That said, whenever I see some "real production" example of Visual Coding only one thing comes to my mind: Graph Maze. I've yet to be proved wrong (and that's not even possible since it's completely subjective) that coding something in Visual Studio + RS/VAX isn't easier than assembling the same logic in Antares Universe. Existing Visual Coding tools don't "scale up" well, when that should be specifically their number one advantage, helping the dev have a higher level control of what's happening and when. Too many games nowadays work okay during Prototype stage and fail to become real games simply because they've been built "from the leaves to the trunk". Developers focus too hard on getting the core mechanic(s) of the gameplay prototyped and fail very hard to integrate it smoothly into a higher level control of the gameflow. When that happens iterative development becomes prohibitive since you haven't planned for scale and modification. It's like trying to define a basketball game starting from the weight and size of the ball, instead of from the size of the field and number of players. You might eventually make it, but it's completely upside-down. In that critical aspect the current visual coding tools approach doesn't help at all, since it's mostly focused on small-scale behavior which is more adequate for traditional, linear coding.

- Visual Scripting (Visual FSM). Finally, there's the concept inherited from process engineering, of Visual composition of Finite State Machines. That's what playmaker uses, and it's definitely a game changer for game developers for the way it makes them think on a higher level and practically "teaches" them to compartmentalize their logic - low level logic blocks in linear text code fashion (actions) and high level logic in non-linear visual blocks (states). The way Playmaker encapsulates and present those actions in each state is ingenious, the more you work with it the more you feel like that's how an OOP editor should work. Nevertheless, it's a paradigm shift, takes some time to grasp, yet the more developers get used to that new way the more they'll realize how superior it is to the "old way". That's not to say that specific tool it's devoid of flaws though, it still lacks some nested/subFSM entity to better encapsulate tiny dependent states and clean up the view of larger FSMs, it lacks some more intra-state algorithm-ish actions (which, although demoted by the author for breaking the concept of FSMs, can be quite handy when used wisely) and better visualization tools. For instance, there's no way to open two FSMs side by side right now, so for any larger design you'll definitely want to use some pencil-and-paper or visio-like tool before implementing anything in PlayMaker. There could be more helpers like event/transition shortcuts (although it has 'global events' which can be used for that) and the ability to selectively turn some transition lines to circuit and others to bezier - currently there's only a global setting for that.

I'm not afilliated with Hutong games in any fashion by the way, but in my opinion if you can only afford one visual logic plugin for Unity, Playmaker is the right option for any serious Unity developer. If you want/need sidekick products to help it as action-generators, great, but really consider checking Playmaker's built-in action code samples, how clean and readable they are - 'look ma, no polymofo-whatever'! Trying your hand at a bit of copy+paste coding shouldn't hurt, not to mention the public actions library is only going to increase as time goes on.

Now, not saying I'd expect that to actually happen, since I know how hard it is, but if uScript has a function to convert its logic graph to standard C# code ready to be used as an action.. I will fricken buy this thing

"Messiah's Crash Course" Video Tutorial Released

2011-03-04T23:22:00.000-08:00

Got 40 mins? Then I can show you how to kickoff with the amazing 3D render and animation package, Messiah Studio, which has just dropped temporarily in price from US$399-599 to US$10-40 (!!) in the remarkable "Dare to Share" promotion by its developer, pmG. This made the relatively unknown yet great software win many adoptors, but that ain't no good if all this new people hasn't got how to learn it quickly and easily. So I've decided to jump on the bandwagon and create three videos (totaling 42 mins) showing some of the very early steps when running the software the first time and learning its ways as quickly and objectively as possible - a crash course.

Instead of repeating what's already explained in the many videos available on pmG's site (www.projectmessiah.com/x6/videos.html), like how to create and tweak a bone deformer or how to use the MDD file format, in these videos I've tried to fill some of the gaps for Messiah newcomers. There's also a clear focus on actually bringing in animation and deformation data from Messiah to other 3D packages, showing how Messiah can, with its recent FBX (Filmbox) export option, smoothly integrate with most other 3D applications. I show Lightwave and Maya import workflows in the videos, but the same principles apply to MotionBuilder, SoftImage and any other software which accepts the almost-ubiquitous Filmbox file format.

It's worth mentioning that the weight map creation from Messiah's procedural weighting is nothing short of stellar, for that one feature (getting you rid of weight painting!) learning it will already provide a big boost to your animated character production speed. Being able to use those amazing skin weights with other incredible solutions like Maya's Dual Quaternion Skinning and Lightwave's IKBooster is the icing on the cake.

Last but not least I quickly go through the process of importing the Messiah-generated animation into the excellent Unity real-time engine, including the position and adjustment of cameras.

Interested already? One last thing - the tutorials are free! So run and grab it while the promotion lasts.. nah, just kidding, this will keep with its incredible low price - ie. US$ zero ;) Enjoy!

Part 1:

http://www.youtube.com/watch?v=VsGa1ulR8Ok

Part 2:
http://www.youtube.com/watch?v=LyymdexYBuY

Part 3:
http://www.youtube.com/watch?v=rgTtUTgnxgg

Project Files:

Messiah-exported FBX File

Maya 2011 Project File

Lightwave 10 Project Files

Unity Project Files

LightKeys for Lightwave 3D Released!

2011-01-17T07:54:00.000-08:00

I'm proud to publicly release the free "LightKeys", an enhanced Navigation and Shortcuts System for Lightwave 3D. It was born out of the need of having similar navigation and item manipulation shortcuts across different 3D applications. As more and more 3D packages and applications adopt the Maya Standard for viewport navigation (Alt+MMB = Pan, Alt+RMB = Zoom), having to switch your mindset to the Lightwave style (Shift+Alt+LMB = Pan, Ctrl+Alt+LMB = Zoom) became a huge hassle for anyone using any other 3D application. To the point that I've seen many Lightwave experts using the navigation icons in the corner of the viewports, probably just to get away from the "navigation disorientation" that results when you try to switch away from the ubiquitous (and highly intuitive, as a matter of fact) Maya navigation standard.

Along the navigation shortcuts change, LightKeys also provides a production-proven shortcuts configuration set with highly increased ergonomy. Basically all the main Lightwave Layout features are accessible from the left side of the keyboard, making the software's operation much more speedy and confortable.

Here's a tutorial video that I've put up to show how to install, configure and utilize it, if you're in doubt if this is for you or not skip to the final 3-4 minutes of the video, where I demonstrate how I use it in production:
Click here to watch it on YouTube (HD)

Screenshot of the LightKeys Tutorial Video

Apologies in advance for the accent, pronunciation and grammar mistakes, here in Brazil English is anything but a native language! :) I hope you enjoy it, comments and bug reports welcome as usual. Soon I'll be making a version for Lightwave Modeler and add enhancements to the Layout version as well.

PS.: Today is my birthday but the present is yours, LightKeys is absolutely free to use!

Click Here to Download

Lightwave 10 Minireview

2010-12-31T13:11:00.000-08:00

Intro

It's true, the 3D sofware market is ruled by Autodesk. People complaining that Maya's humanIK is a half-hearted, hacky implementation of what MotionBuilder does so well, are right. People complaining that Maya doesn't get better modeling tools because of 3DSMax, people complaining that 3DSMax's CA tools are kinda lame compared to what you get in Maya, and even who complains that nothing in Maya or Max hold a candle to what Softimage's ICE technology can make - also have a point. Sadly for the evolution of the industry, there's no longer any 3D software war out there, whoever thinks so is making a fool of himself. It's basically all Autodesk property now, they can do whatever they want with it - including make sure that these softwares keep as segmented as possible, so as to maximize sales of all the packages for each client. Does that make any commercial sense to you? That considered, there is only a handful of full-featured contenders out there against the Autodesk "one company to rule'em all" approach - Cinema4D, Houdini and Lightwave 3D being the most notable ones. Among them Lightwave is, by far, the most mature platform, with no less than two decades of technology development to back it up.

I'm personally as much of an "ancient lightwave user" as anyone can be, having been a beta tester of the software (0.9beta or so) back in the joyful Amiga 500 days. I still have fond memories of the old lightwave-list, I think we had just 10-20 posts per day back then, and the developers (read: the two coders) had the opportunity to reply to each one of us. Good ol'times.

Although it seems like yesterday to me, twenty years have passed since then, and in that period of time Lightwave took many forms and shapes. It went from "the Video Toaster 3D program" to an obscure 3D PC software right after leaving the Amiga platform, to a "niche" top studios 3D application, responsible for the amazing effects of many great TV and movie productions. As evolved as the platform eventually became, the fact is that Lightwave's 9.6 release (early 2009) didn't offer as many enhancements as the community, both amateur and professional, expected. This has split the community apart sensibly, since most started using other 3D packages, either in parallel with Lightwave or substituting it altogether. The fact that the Autodesk-standard FBX file format importer/exporter wasn't as compatible as it should isolated Lightwave even more from the other 3D tools, a critical mistake in an Autodesk-owned 3D world. It was simply less of a hassle to move the whole pipeline to Maya, Softimage or 3DSMax.

By the way, I know this is not exactly short, yet I call this a mini-review because to fully review such a vast application like Lightwave anyone serious about it would take at least a couple months, and the resulting review would be 5x bigger than this. Instead I'll be mostly focusing on the main improvements and what has changed in the software that can actually make artist's lives easier. During this review I'll also make some comparisons between Lightwave and Maya, not only because the second is the other full-fledged 3D application that I'm most intimate with, but also because Maya is the major-3D-studio app of choice, making it a kind of a benchmark.

Character Animation Improvements

Character Animation has long been considered the achiles heel of Lightwave 3D. Version 9.5 included multiple enhancements in this specific area, but poor documentation and the lack of more advanced tutorials to perform high-quality rigging in Lightwave - like the ones you can easily find for Maya in the likes of Digital Tutors and Gnomonology videos - ended up making wannabe Lightwave character animators "knowledge orphans". It literally took man-years and a number of talented and resourceful Lightwave artists to fully decypher things like the inner differences between joints and bones, or how to properly integrate IK and the arcane IKBooster interfaces seemlessly enough for production purposes. Thanks to the efforts of these brilliant lightwavers, nowadays there's little to nothing that can be done in Maya or Softimage that can't be done easier/faster in Lightwave. IK/FK switching, for instance, is a default animatable setting in Lightwave's IK, while Maya riggers waste precious time to have the same setting in their rigs. Even so, there's still a lack of "official" resources for most of the Lightwave CA affairs, and training material is relatively scarce. Nevertheless, the Lightwave community forum is probably the most warm and welcoming 3D community in the scene, it's very easy to find intelligent and extensive discussions about pretty much any topic, just as it's very common getting help from the biggest experts in Lightwave. Ah, the beauty and warmth of un-bloated communities.

Back to the CA matter, Lightwave's approach to skinning is remarkably different from that of other programs, and probably its biggest highlight. You can interactively rig anything instead of having to fiddle with weightmaps for hours before getting any kind of decent deformation. For instance, while testing a rig, I've deleted a handful of unmapped joints right in the middle of the animation process. It all simply worked as expected - or unexpectedly, if you consider the "norm" of other 3D CA tools except for Project:Messiah. Pose deformation (like a bulging muscle) can be easily achieved both procedurally and interactively using the built-in SoftFX component - also exceptionally competent for advanced effects like soft bodies and hair physics.

This all sounds great, but it's nothing new to be honest, it's just an intro for this final paragraph if you're not aware of how things work in the lightwave-world. The point is, the biggest drawbacks in Lightwave for Character Animation up to 9.6 were: 1) the slow deformation speed, making the animation process slower and tedious than it should and requiring workarounds like proxy meshes and 2) The half-baked FBX import-export plugin, that couldn't really handle some advanced settings. I'm glad to say that this is now all in the past. Not only is the deformation speed much much faster, on par with Maya 2011, but the FBX plugin has been vastly enhanced, providing seamless integrations with MotionBuilder (aka Mobu) if you require its Human IK rigging or advanced mocap editing features. It's worth to note that Lightwave does have some nice Mocap editing features with its IKBooster component, for most applications that might be enough and free you from the steep Mobu purchase cost. As for raw animation deformation performance MotionBuilder is still the king of the world, but it's worth mentioning that Mobu has no real-time subdivision capability, nor a magnificent VPR that shows you interactable x-ray bones overlaid on top of a fully rendered scene.

The renderer

For those inexperienced with Lightwave 3D, if I could describe its rendering in short I'd say something like "The only full 3D package's native renderer worth using". Compared to the other major players (Maya, Cinema4D, 3DSMax and XSI) native renderers, it's ridiculously superior. Sure, some will rush and say Mental Ray is now native for Maya for instance - I beg to differ. Some advanced plugins require major tuning to work properly with Mental Ray, and even when they do the result is largely different from the native renderer. When I say "major tuning" I mean "generous chunks of time wasted tweaking shader node networks and playing trial-and-error with slow and zero-feedback non-native renderers".

I still remember the days when Lightwave 3D sold one license for each fPrime license sold, and not the other way around. fPrime was the first of its breed, not exactly a VPR since it has no actual viewport overlay. You usually had its window opened as an instant render feedback while manipulating scene itens in the main application window. This worked really well, but it wasn't completely compatible with everything Lightwave had to offer, like Hypervoxels (for advanced volumetric particle effects) and even the most advanced shaders provided in the latest v9 releases. Slowly Worley Labs caught up with most of it, but most of the time you ended up wasting some of your time in the end with actual Lightwave renders, which was a bummer.

And here's Lightwave 10 VPR. Trust my words, nothing I've ever seen compares to that. Coming from a huge struggle in a complex Maya scene just trying to tweak textures and get the intended results, this is seriously night and day difference. The performance is outrageous, humbling even the mighty Modo interactive renderer, and that goes without saying that Modo (even with the just released 501 update) has no character animation tools. VPR is able to outperform even the regular Render, which got huge speed buffs on its own - and, most importantly, whatever you get from VPR is exactly what you get out of Lightwave render buffers. Oh, the joy!

If you want to consider some alternative viewport real-time renderers (VPR) for Maya, you'd better be warned that you won't have a high success ratio with 3rd party plugins. Of course you might get lucky, that's just an alert so you're not caught with your pants down when the client asks some specific effect and you think that shiny new real-time render plugin will save the day and make you look good. It might work for all you need in one or another scene, but hardly with the interactivity you'd want under a tight deadline. Alas, that means a great chance of missing that deadline and end up looking bad instead. My point is that having an 100% native VPR engine is not just amazing, it sets a new mark for consistency and reliability. You won't get this, for instance, out of the spanking new Arion or Octane render engines, the first being quite limited in terms of what it can render so far, and the second using some tricks to speed up rendering, tricks which will not only lower your render quality, but which generally lead to different preview results than what the final renders deliver.

One glitch I used to have with the otherwise outstanding LW renderer was with the crispness of the antialias. It either didn't AA well, or it did a way too soft AA. For photoreal rendering this is generally desired, but for toony rendering you really want some extra crispness to reach a more "Pixar-like" look. I got extremely pleased with the software new AA modes, including Lanczos and Mitchell Sharp filtering, I got very nice MentalRay-AA-like results with marginal render time increases.

One of the most glaring of this low-cost powerhouse renderer limitation - which has made many jump the boat off to boring pastures - is the lack of render passes. Render passes, the ability to output separate images with isolate diffuse, specular, shadow, etc, with a single render might seem unnecessary to the hardcore old hats (again, like me), but once you enjoy the pleasure of precisely tweaking every minor shade of your render in post production (After Effects, shake, etc), it's really hard to look back. Unfortunately, this important feature hasn't got into Lightwave 10, at least not natively. That said, there ae some limited buffer exporting features in its lastest incarnations, individual render buffers which can be vastly extended by some third party tools and libraries - all well worth researching.

Technology and Extensibility

It's important to mention that Lightwave 10 still uses the ancient original LW inner code structure, and inherits some of its limitations. The touted "CORE" technology announced last year still hasn't culminated in a full product mature enough to fully replace the current tech product, so Newtek wisely decided to migrate some of the key CORE improvements to Lightwave 9.6 and release it as Lightwave 10. It really takes time to re-invent the huge wheel which Lightwave has become, something that Newtek has vastly downplayed considering its initial release schedules. Yet this re-invention is much needed to allow things like an integrated editor - instead of two separate yet inter-communicating applications - and finally a modeling environment on par with the polyon-crunching leaders, namely Modo and 3DSMax.

Nevertheless, what seems like a drawback some times it's a huge advantage. The consistency and backwards compatibility of the Lightwave engine means you've got a ton of free and cheap plugins and lscripts (Lightwave's lower-power "MEL" equivalent) developed along all those years, most of them working and of huge help up to this day, be it for modeling, animating or special effects.

Conclusion

Newtek really expected to have a decent Lightwave Core release before the year's end. This wasn't possible, but at least they are to praise for avoiding the Autodesks low standards of releasing and charging users for pre-beta software in desperate need for Hotfixes that'll only come out months later. Maya 2011 anyone? It's hard to believe that even the much needed "component editor" in Maya wasn't fully operational when that program was released, and even after a couple hotfixes and one service pack that's still the most unstable and crashy major 3D application in the business. Trust me, even the finicky Modo 401 seems stable compared to it. In the other hand, Lightwave 10 has been stable for months now, and its version "10" wasn't released almost one year ahead of 2010. Ahem.

The fact is, on such a saturated and monotonic business environment, for Lightwave to recover some of its share - and, hopefully, gain new ground to assure further development - it can only rely on its new and unique features, besides what it already offered. Lightwave is a true fully integrated solution with CA tools, hair, rigid and soft dynamics, without any 3rd party plugins required, coupled with excellent quality renders - no MentalRay or V-Ray required for you to scratch your head about which material or shader works and which doesn't. VPR is an outstanding addition which completely revamps the way and the frequency in which we artists shape up the final resulting image - which, in the end of the day, it's all that matters. The new built-in 'Linear Workflow' lighting system is yet another powerful weapon in the Lightwave arsenal to achieve this exact purpose, and artists will surely take huge advantage from it.

To sum things up, this is the most powerful, most complete and most innovative Lightwave release in many years, fully honoring its traditions of the past when Allen Hastings and Stuart Ferguson were still leading the boat, pushing the 3D envelope and being the first to release high-end and industry-defining technology like radiosity, particle voxes and subdivision surfaces for personal computers.

It's great to have you back in your new shining armor, Lightwave. Such a warm feeling!

Movies, games, media et all

2010-07-21T05:25:00.000-07:00

As posted in a reply to this blogpost in Gamasutra:

We should cut it off once and for all. Simply put, it's utterly pointless comparing games to films, just as finding frustration or looking for culprits in games not being able "so far" to achieve the same high level of public acceptance or academic recognition. They're on absolutely different leagues.

When you go watch a movie, you lay down on your couch or back at your chair and you relax. It's a passive endeavor and, no matter how much the film provokes the viewer, it'll keep being so. Nothing you can, as a viewer, do may impact the story ending - it's storytelling in its purest form. That's what our brains are used to in terms of enjoying storytelling, it provokes a deep-rooted form of pleasure related to learning. The possibility that such pleasure can be caused by language communication and not only by visual or sensory experience is the one best differentiator that we as a species have from the other lifeforms in our planet. In the same token, reading a book is so much more thought-provoking and adequate for the primal story-telling receiver experience than movies. Shapes and forms are created by your mind, an exercise generally leading to images derived from experiences and visual elements we've been exposed to along our lives. That brings each block of text you read, each new scenario described, many steps closer to "pre-acceptance", simply because your brain accepts as good representation anything it has stored or created on its own.

Compare these two media experiences to the gaming experience for a second and you'll easily realize how absurd such comparisons are. Games are interactive, like it or not if they're not interactive they're not even games to start with. Not only you need the proper mindset to be willing to interact - which also means accepting the possibility of failure doing so - but it's also a much more demanding activity, be it perceptually or sensorly, generally both.

Even as a former hardcore gamer, many times I find myself choosing to watch a movie over playing a game not because current games aren't like this or like that, it's because a movie it's an "easier" experience - and all I want to do is relax and be (usually) granted a nice experience.

We as game makers have to invest such an insane amount of time just to make the interaction with the game media we're providing easier/smoother, to make sure all possible angles of action are "believable" or acceptable by our intended target audience (and don't think for a second that movies don't have to do the same), that it's easy to get lost on that and put aside or forget some or many essential content and experience enriching elements to the media.

My point is that with game media, we're not just trying to reverse-engineer one mind so that we can shape up a proper experience for a vast spectrum of possible actions a certain player might take in a given situation - a task incredibly hard on its own, ask any psychologist. No, we're trying to do it en-masse! While we don't accept the fact that that's a ridiculously harder endeavor than film-making or any other non-interactive media, we'll keep feeling bad about the industry results as a whole, and trying to point fingers to why we're "falling short". In fact, as much as there's room for improvement, we're far from that. Lack of understanding of our own media is our main downfall.

We don't need multiple new and amazing 'auteurs' to improve the situation - we might need entire new generations to come, with different responses to stimuli written in their 'mental firmware', to even dream about peaking in our business. And that's one of its brightest and most motivating beauties :)

zBrush displacement in Maya

2010-06-07T06:45:00.000-07:00

Displacement render in Maya / Mental Ray. Notice the very fine 'length size' of the approximation, to capture all the detail.

As trivial as rendering a detailed Mudbox sculpt in Maya/Max/SI is - even easier and better now with Wayne Robson's new vector displacement shader - fact is that sometimes you really need to render your zBrush sculpts in Mental Ray. Here at FluidPlay Studios we use an extremely high-quality process for Ambient Occlusion generation which involves using a dedicated "generic lighting scenery" that not only computes for the ground plane (instead of the traditional ground-ignorant Ambient Occlusion methods) but also does it using radiosity / global illumination (GI) to achieve the best shadows available to mankind. The price to get all this quality is pretty steep, since it's not possible to get the best quality GI renders without actual displacement maps, mere normal maps won't cut it. So, supposing your model hasn't been sculpted in Mudbox, how to properly export and render your zBrush detail into Mental Ray? Especially if you're using the latest zBrush releases (3.5), here goes a few guidelines that might save you a world of frustration:

zBrush 3.5's displacement export is inflexible and it sucks, get away of it. Use zB 3.1 instead. Although the file format is not compatible, there's an easy workaround.

In 3.5, export the highest sub-d level as obj. To increase the chances that your lowest level (generally a re-topologized mesh) isn't distorted, before exporting the model make a few "propagation" passes. Propagate is simply to move a few subdiv levels up (generally two levels are sufficient), go back to the base level and re-import the original mesh. The more you do this, the less you'll see the mesh change each time you import it back in sub-d level 0. Of course you can use morph target instead of re-importing, some people are just scared of it - and to be honest that 'switch' command is quite confusing and error prone - so use whatever you prefer.

In 3.1, import the obj and go to geometry -> reconstruct subdiv. Do it as many times as you have sub-d levels in the original file.

If you want to send your zBrush to Mudbox for retouch or vector displacement export, the best method is probably using the "PN8" option in zBrush 3.1's Multi-displacement exporter 3 plugin (MD3). Apply the positive and negative layers in two different mudbox sculpt layers with values +100% and -100% each. http://www.pixologic.com/docs/index.php/Predefined_Configurations

Before using the MD3 plugin, please notice that the main displacement settings DO affect MD3 export settings. After must fiddling, I've found that you generally get the best quality maps with a smooth-edged UV map (try hiding the seams as well as possible, that's common UV practice anyways) and setting smooth uvs to off, adaptive to ON in the main displacement setting. If you have completely closed model (ie. no skirts, sleeves, etc) smooth UVs are the way to go. Also, if you really need UV edges in important/visible areas, you might consider using the smooth UV option, when it's on it'll only "break" open edges generally, due to approximation errors between zBrush and Mental Ray's way of smoothing things out along subdivision. If you have a hard-edged model by all means disable smooth UVs.

In the MD3 options, set the following:

UDim 0
InitialFileIndex 1001
MaxMapSize 2048 (or 4096 or 8192 depending on your resolution requirement/RAM)
MapSizeAdjust 0 (extremely important)
DpSubPix 0 (also extremely important)
Border 4 (or 8, that's your texture "UV bleed" so use it wisely)

Click on "Export Options" (still in the MD3 window), click on the second button (R32), click on Quick Code and enter the following:

DE-LDEK-EAEAEA-R32

Click on Create All and be happy with your just created high-quality displacement map :) For info on how to plug it to Maya/Mental Ray, I highly recommend checking out these two links:

http://www.pixologic.com/docs/index.php/ZBrush_To_Maya_Displacement_Guide#Displacement_Maps_and_the_ZBrush_Alpha_Displacement_Exporter

http://vimeo.com/groups/41328/videos/6625954

For the record, zBrush 3.5 normal maps are much superior to zB 3.1's standard normal maps, so stick to your normal map generation in 3.5. If your re-built low base mesh differs a lot from your original base (highly unlikely), and you want to use the re-built base instead, generate the normal maps using MD3 as well, using the N8 option.

Credits go to CannedMushrooms for the massive groundwork and great code, shared on http://www.zbrushcentral.com/showthread.php?t=49443.

Projection/Displacement workarounds

2010-06-02T00:26:00.000-07:00

If you're serious about high-end 3D content generation, you'll eventually run into "displacement map" generation (that thing that makes a low poly model become super-detailed at render time). As Bill Gates probably once said, "with huge power comes huge bugs", and so it's almost impossible to avoid the displacement maps associated limitations and inconsistencies across applications. Here at FluidPlay Studios, we've been suffering a lot with displacement generation in zBrush as of 3.5. To project the high-frequency details of some 3rd party models into our re-topo'd low poly meshes we've had to resort to multiple gymnastics, here's a quick rundown:

- Divide low poly cage only up to level 3 (keep original base stored as morph target in level 1, ofc)
- Use project all. Limiting yourself to level 3 will mean project all won't completely ruin your day. Just partially.
- Send the level 3 model to Topogun to re-snap the tricky edges to where they should be relative to the high poly model.
- Bring level 3 mesh back again into zBrush, import it over level 3 ofc
- Divide a couple more times - we avoid going over 6 to keep fixes manageable, also detailed enough if your cage is well topo'ed. If your edges are really tricky and you need to preserve them, try dividing to higher levels with smoothing off, or maybe one divide with smooth off and the next one or two with smoothing on. Your mileage will vary.
- Super-important step - MASK THE EDGES. Edges don't project automatically well, period. Go up and down sub-d levels as needed to make this easier.
- Soften the masked edges and run another project all (this time you should be on level 5-6)
- Turn on that *blessed* culling auto-mask feature in the brush menu, that'll help tons with the project brush in edges
- Invert the masked selection and start using the project brush to bring in some edge detail. I recommend not being too picky here, it's generally not worthy, if you did a good job in the topogun phase it should be enough.

From there on it you should get a clear map by turning off adaptive (it's broken in 3.5) and using 32-bits. Remember to restore your morph target in level 0 before generating the map, and turn on Flip V if you're sending it to Mudbox.. or anywhere else for the matter. Cra-Z-brush and its annoying non-standardnesses.

Anyways, best bet by now, if you've also got Mudbox, is probably using it to generate displacement between a mid-poly mesh and a high poly one. A little trick if you go down that route: use decimate in zBrush first, to pull the poly count to slightly under 1 million. Otherwise Mud will fall down to its knees and probably crash or be to slow to be usable. Also don't select the objects using the object manager, just "add all" for each item (low/hi) in the map extraction window and remove the one you don't want. Life saver. Just remember to check your UV subd algorithm vs the one that your render app uses (for instance, Renderman uses smooth UVs). Also notice that Mud doesn't have any "project" brush so you can fine tune its projections, so you might need to go back to zBrush to manually fix some issues (always a tricky trip when it involves displacement), or just use photoshop to fix things by hand if they're minimal.

Oh, for the record, Vector Displacement Maps (VDMs) are already a reality in Mudbox 2011, and can be easily rendered in Maya/Mental Ray using Wayne Robson's plugin. Differently from standard displacement maps though, don't expect to generate VDMs in Mud for anything that comes from the outside - which's quite narrowing for most pipelines.

Well, that's it for now folks. Good luck!

Good'ol days

2010-01-03T04:50:00.000-08:00

First and foremost, I'm not a Mac fanboy. I'm actually an Amiga fanboy, and since that machine is deceased since like forever - and no one is competent enough to ressurect it - that makes me a platform-agnostic. Just as when your team is already disqualified from the season and you're just watching the other teams play the finals because you like the sport, ya know?

So, 2010 is here, I'm fifteen days away from my 36th birthday, and then I stumble on this video:

http://www.youtube.com/watch?v=G0FtgZNOD44

When you've lived those days, when such "simple" things that Mr. Jobs showed were almost impossible dreams, and watching this video brings tears to your eyes, you know you're getting old :) It's great being able to put all the technological evolution in the right perspective though, something the younger can't really do. And just so this doesn't sound like loser's talk: I can use a Mac ;]

Happy new year!

Maya vs Max - yet another comparison?

2009-11-20T20:31:00.000-08:00

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.

Re-topology should be a thing of the past

2009-11-08T05:56:00.000-08:00

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.

The dying RTS genre

2009-09-13T21:27:00.000-07:00

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.

Emergent Game Design still emerging?

2009-08-20T22:27:00.000-07:00

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

Lightwave to MotionBuilder

2009-08-08T09:54:00.000-07:00

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: http://www.pcpages.com/nilesh/yo_mirwgt.zip
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

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)

Character Anim Woes

2009-07-30T23:16:00.001-07:00

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.