A Carrara 8 test

I finally took advantage of the deep-discount offer on Carrara 8 Pro provided by 3D World magazine issue 133, which shipped with a copy of Carrara 7 Pro on the enclosed DVD plus an upgrade-to-8 offer. This animation is a variant of previous work, however here the rendering is done in Carrara, which also provides the sky and ground plane. Daz Studio could also of course provide the ground and the drop shadows, though it doesn't do skies. The embedded video below isn't high-def, so for the better (720p) version, go view it directly on Vimeo and click the player's expand-to-fullscreen button.



The workflow here was fairly simple:
- Save the previously-created (and animated) Daz Studio version using the "Daz Collada" format, the Daz variant of Collada designed for moving scenes from one Daz program to another.
- Load into Carrara.
- Fix the hair.
- Create ground plane, sky, lights. Animate the camera a bit at the end.
- Render to TIFF
- Assemble and add music in Premiere Elements 4.

Problems noted:
- The hair element didn't import properly into Carrara - it came in with no texturing as a solid grey mass. I had to remove the hair and reload a copy of the asset from directly within Carrara, reparenting to the Aiko3 figure. This problem suggests a bug in either the Daz Studio method of exporting parented hair assets, or Carrara's method of importing them.

- Daz Studio uses z-axis forward, the standard for most 3D programs, including every single Autodesk tool that I'm aware of. Carrara, however, uses z-axis up, which is much less common. The result is that any attempt to load my Daz-friendly BVH files directly onto a figure in Carrara results in what are essentially garbage keyframes on the hips, for both rotation and translation. This is a major failing on the part of Daz, which simply should not be shipping two separate 3D products that use an inconsistent xyz view of the world. Different xyz axis orientations is a classic situation that often makes it nearly impossible to move assets and scenes smoothly from one 3D application to another.

I could understand this difference in axis orientations if Carrara were a new acquisition for Daz, however Daz purchased Carrara several years ago and has now had at least 2 release iterations (versions 7 and 8) to standardize on the industry-standard z-axis-forward orientation.

However, in general the process of shifting a scene (with keyframes) from Daz Studio to Carrara was cleaner than most export-import processes I've seen, including Autodesk fbx, which has traditionally been a mess even when you're moving from one Autodesk product to another.

The cgspeed Daz-friendly release of over 2500 BVH files is now available

I'm pleased to announce the most recent BVH conversion of the Carnegie-Mellon (CMU) motion capture library. The new conversion is for the Daz (daz3d.com) 3rd-generation and 4th-generation characters such as Aiko3, Aiko4, Victoria3, Victoria4, Michael3, Michael4, and so on. Over 2500 separate BVH files are available, with an index. You can get the files right here at cgspeed.

Other people have previously done releases of the CMU motion dataset for the Daz characters or "for Poser", however sometimes there are significant problems using these earlier releases. This new "official cgspeed.com" release was created via a full retargeting in Motionbuilder, and is designed to import seamlessly into programs like Daz Studio when you use any of the Daz gen3 or gen4 characters.

Two training videos are available (in HD):
Part 1: www.vimeo.com/13777740
Part 2: www.vimeo.com/13777422

This Daz-friendly release is actually two separate releases: a "primary" and a "secondary" release. The difference between these two releases is explained in the second training video, and in the full READMEFIRST file of the primary release. Generally you should start with the primary release, and only get the secondary release if you think you need it -- see the second training video for an example.

Thanks to John Lukasiewicz for doing the initial heavy lifting on the Motionbuilder Python script that enabled this release. No thanks to Autodesk for having bugs in their BVH export code, which I had to correct around. :-O

AFFILIATION AND DISCLAIMER: I (Bruce) am not affiliated with and don't speak for Carnegie-Mellon University, Daz Productions, Autodesk, or Smith Micro, and they don't speak for me. :-)

Animazoo Gypsy 7 announced - now under $10K

Picture: the Gypsy 7 suit (on the right). The left suit is Animazoo's
inertial-based system, so ignore it - that's not a Gypsy 7

I received an announcement today about the upcoming Gypsy 7 motion capture suit from Animazoo. This is the successor to the Gypsy 6. Some official information is at:

http://www.animazoo.com/index.php/gypsy-7
http://www.animazoo.com/media/pdf/Animazoo_GYPSY7_Brochure.pdf

Here's a 3rd-party page on the predecessor Gypsy 6 system, for comparison:

http://www.est-kl.com/products/motion-tracking/animazoo/gypsy-6-technical-specifications.html


Gypsy is a potentiometer + inertial based system rather than a marker-based system. So the big advantage is you don't need cameras. Another advantage is that you're not theoretically limited by a capture area. The big disadvantage is that the performer's motion freedom is limited by the suit - you're not going to be doing complex martial arts demonstrations in one of these.

The huge difference from the previous model is the 3x (!) drop in price. A Gypsy 6 full-body system was about $25K, but Animazoo is claiming an entry price of $8K for the Gypsy 7, before software drivers. So a Gypsy is now in the same under-$10K price space as a Naturalpoint camera-based system. The Motionbuilder driver set is an additional $1000.

An email exchange with the U.S. distributor indicates that Gypsy 7 is a USB-tethered system. The Gypsy 6 could be run in wireless mode. The tether seems to me like a significant disadvantage - you don't want your performer to have some long USB cable snaking off the back of the suit to your computer for the data capture. One great thing about wireless no-camera mocap systems has always been that you can dump a performer into the middle of a field, or a parking lot, or whatever, and get data -- your capture area is the largest public space that you can find. So it's unfortunate to lose that for the Gypsy 7. I wonder if it would be possible to trick up something via consumer-grade wireless USB hardware.

From the pictures online, I wonder how well the suit is going to pick up full head and neck rotations. That looks like a solid bar pointing up the spine towards the head. But until somebody gets to experiment with one of these, it's hard to tell.


Disclaimer: I don't work for Animazoo, nor do I resell their products.

CMU motion capture BVH release for Daz characters is in progress

Here's a 60-second test video that I made with a BVH file from the upcoming Daz-friendly conversion of the Carnegie-Mellon BVH dataset. I'm working on a new conversion which will complement the existing motionbuilder-friendly and Max-friendly releases. There has been at least one previous Poser-oriented conversion of the CMU dataset in the past, however investigation suggests that it has quite a lot of problems with bad joint rotations. This new conversion should avoid the problems of previous releases.

Blender for fan anime

Blender (with After Effects) comes of age for toon-shaded, anime-based fan animation. Related sites include a brief BlenderNation article, and the creator's own site. Note the use of physics-engine-driven hair (both videos) and cloth (second video). Note how the hair and cloth are treated as fully-qualified objects which collide with the body geometry instead of intersecting it.

HapiLoli from tomo on Vimeo.

ルイズ／恋愛サーキュレーション from tomo on Vimeo.

Dancing 3D avatar software

While it's not going to be iClone any time soon, the free software Mikumiku Dance appears to allow a fair amount of animation capability if your thing is making dancing 3D anime-style avatars. The software is originally Japanese, however an English release is available and several training videos, available at the same link, have also been subtitled in English. The software incorporates the Bullet physics library, presumably for the cloth and hair simulation on some of the models.

Other potentially useful sites:
Miku miku dance wiki
Miku miku beat

When you combine the software with live camera tracking and compositing software, you can end up with results like this video:

What the hobbyist animation community needs

I recently received email from somebody in the animation software industry who wondered if I had any comments about the capabilities that hobbyist animators needs. Below is an edited version of my response.

1. Animation software

Hobbyists need an animation application with the capabilities of 3dsMax at a pricepoint of $500/year or less, not the current $4000 startup + $500/year maintenance approach, with workstation lockdown via licensing keys, that Autodesk presently charges. Fundamentally Autodesk is a problem for hobbyists because Autodesk has zero interest in the hobbyist market.

The three lead candidates for an animation app that might meet people's needs sooner rather than later are Daz Studio, which seems to be adding some rudimentary animation tools, but has a long way to go; iclone 4; and Blender 2.5. However iClone's business model is focused on selling their own proprietary content packs, not on importing Daz or other characters or clothes. Blender has not been a solution to date for a variety of reasons, including a user-hostile interface that doesn't match anything else in the industry; lack of a full scripting API which makes it impossible to write simplification tools; and a lack of usable .fbx import. Blender 2.5 claims to fix some of the UI problems, however version 2.5 is only in alpha and won't be in a less-buggy release for another 6 or 9 months or whenever they feel like getting around to it.


2. Motion capture

Hobbyists need a prosumer motion capture system that produces clean, professionally-usable capture data, can be built using high-end consumer-grade webcams, run at home on a laptop, for a total system cost of under $2000. A good NaturalPoint system presently goes for $10K, the cameras are proprietary, and they have a lifespan of perhaps 2-3 years until the next generation of cameras comes out. NaturalPoint is obviously much better than Vicon, which is completely out of hobbyist range, but fundamentally you're not going to see hobbyists doing home mocap-for-animation until the price point drops by another factor of 5 to 10, down to under $2000 including the cameras. There's a chicken-egg problem here: NaturalPoint has to charge $10K for their software + cameras because the market is small. If the market were 10x larger because it expands to include hobbyists, they, or somebody with a similar system, could drop the costs.

I don't presently have a lot of faith that low-end markerless systems such as IPI's Desktop Motion Capture, which maxes out at 4 cameras, will produce capture datasets that are realistically usable without huge amounts of cleanup.


3. Very easy content portability

Hobbyists need very easy, 100% reliable content migration and import from content sold for hobbyist applications like Poser and Daz3D into animation engines. All of the Daz characters should be trivially importable into Blender and all Autodesk applications (and C4D and LightWave), with rigging, skinning, and morphs intact. I'm not interested in static .obj file export/imports where I'm told "now just go skin it and rig the mesh yourself in your animation software" -- I've spent hours trying to skin Daz characters within 3dsMax and the results are still unusable, because skinning is a specialty skill. I don't want to have to build up my skinning skills to the level of expertise required to skin a 120,000-vertex character for semi-professional use -- I've already purchased the Daz content which is skinned within Daz3D, it should work in my other 3D applications as well. Nor I should I need to spend 10 hours reverse-engineering what's going on with the textures to make the eyeballs look right, which is what you have to do with Maya or Max today when converting a Daz figure.

I should then be able to purchase content at Renderosity or Daz -- at their consumer-level prices of roughly $5-$30 for some clothing items, a vehicle, or a set -- and trivially load it into my commercial 3D application, again with morphs and textures intact. I should be able to buy clothing sets for the Daz or Poser characters and easily pull them in to the animation software to use on the figures. This process works in Poser just fine, but Poser isn't an animation tool, it's a still-figure posing tool that isn't usable for serious animation work.

In my experience, none of the tools or formats that claim to support 3D asset migration work properly or cleanly. Not once have I seen a Collada export-then-import process successfully maintain skinning, rigging, textures, and morphs. FBX import/export tools don't work either -- even Autodesk can't get this right within their own product lineup; they release a new flavor of FBX exporter/importer every 12-18 months and you have to synchronize your FBX tool flavors to have a chance of even making a Maya-to-Max or Max-to-Maya conversion work. Pcharacter2FBX, brokered through Daz, comes close to performing as advertised, however even it does things like mess with the underlying bone structure of Aiko3, and it doesn't work on the 4th-generation Daz characters since it hasn't been updated in years.

Max also is severely limited because it only supports 100 morphs per mesh geometry. Even Aiko3's full morph set is around 200 morphs, and Daz V4 is probably many more than 200. So right now it's not even possible to pull the Daz 3rd-generation characters into 3dsmax and preserve all their morphs without an expensive 3rd-party morph-extender plugin.

I've also found that when you import .obj files into Maya, none of the file-based textures come in, so you have to replace them by hand. That's another example of the import-hostility of current software. In the Autodesk world if you're not using 100% Autodesk and .fbx, you're expected to have an on-staff Python/PERL/MEL programmer who can write fixup scripts and design your data-migration pipeline for you. No hobbyist animator has the time to do that, nor should they have to learn Python.