The Adventures of Tintin
> 3D
- Tuesday, October 18 2011 / The Adventures of Tintin - trailer
- Saturday, October 8 2011 / Coral alpha
-
Long time no see but I’m still alive!
The last 8 months have been pretty busy at work but with the wrap of The Adventures of Tintin I can finally put a term to my hibernation. I’ve spent most of this time creating a rig for a bird and developing a generic and modular workflow to build rigs and any kind of asset in an object-oriented, nodal based and consistent way, pretty exciting!With a 5-years background as a XSI user, the transition to Maya when I arrived at Weta was quite straightforward but not really pleasant. I eventually ended up seeing the advantage of having access to the Hypergraph and being able to build my rig/deformer graphs in there, but still... on top of having to deal with poorly designed tools (what a nightmare to paint skinClusters in Maya!) and an API that looks like a mess where you have to write all the basic functions yourself if you’re planning to use it, my main frustration comes from not having access to an ICE-like graph to create my own deformers. I really miss this quick and intuitive process... accessing mesh data, dealing with minimalist building blocks, plugging nodes around and immediately see what happens, visualizing any node output to debug and see what’s going on, etc...
Once you get used to this workflow, it becomes hard to do without it. It would feel like driving a car with the handbrake on. ICE is simply invaluable when in example you’re on a tough prod and need a deformer but don’t have the time to prototype and develop a C++ node for that. Furthermore that node might be a bit too specific to your problem and might not be worth developing if you can’t reuse it later on, or might take too long to extract and implement a more generic concept out of it.
Fortunately this frustration is now coming to an end!
Andrea Interguglielmi just released a new procedural application in alpha version: Coral [en]. The goal is to provide the users with a nodal-based interface where you have all the very basic building blocks and can create complex graphs out of it to then package them in a single node if needed. You can create your own nodes, you can create your own attribute types, … you can do pretty much what you want basically.
You’ve got it, it’s quite similar in the idea of ICE and it’s a pretty good thing! The main advantage of Coral is that it’s a standalone that can be plugged into different packages so you can now do one rig or one deformer and use it in Maya, XSI or whatsoever. How neat is that?
An integration for Maya is actually already built-in and seems to work seamlessly according to this video [en]. I haven’t tried the Maya integration yet but I managed to build a simple and stupid deformer, which is really encouraging.
A deformer test in Coral
The deformer's graphAs this is an alpha, it’s missing quite some features and nodes to make it usable as it is in a production context, but once again nothing stops you from creating your own nodes and own attribute types and customize it the way you want.
The application is actually open source and works on Windows, Linux and Mac. For now the only binaries provided are for Mac but you can download and compile the code for your OS - I tested it on Linux at work and it runs fine.
External links:
- Saturday, June 4 2011 / Rise of the Planet of the Apes - trailer
- Tuesday, February 22 2011 / X-Men: First Class - trailer
-
Matthew Vaughn [en], the director of Kick-Ass, is back on track with X-Men: First Class, a prequel telling the origins of all we know about those superheroes.
I'm not a fan of the X-Men movies but this one has a good potential, fingers crossed.Weta Digital is behind some of the FXs that you can see in the trailer.
X-Men: First Class
X-Men: First Class
External links:
- Sunday, February 6 2011 / Eyelids prototype - the rig!
-
Two years ago, on a previous post, I said that I was planning to release this eyelids rig sometimes in a future release of my ccRig. Unfortunately it didn't happen and might not happen in a while so I guess it's better to release it "as it is" rather than not at all.
As this rig is quite old and still in a state of prototype, you definitely won't find in there anything finished, optimized nor nicely organized. It's actually far from being so. Also the rig provided adds another layer of complexity by adding the useless and impractical (but nice to demo) ability to animate the controllers sliding on top of the geometry. It might be a better idea to just create a separate interface as it would be easier to animate (the animators won't have to zoom in the view to be close enough of the eye and the controllers won't disappear somewhere under the geometry) and easier to rig as well.
That said, the good thing with that rig is that it might still help to give you the global idea. Also keep in mind that this rig is quite simple and helps achieving good results for specific and simplistic cases but it probably won't be the ideal solution for more complex requirements.
Using UV space to determine the target of the eyelids in the blink state.Speaking of that idea, it's actually very simple. Let's quickly overview how to create a rig to make an eye blink while still being able to be deformed by the bulge shape of the eye.
Each edge line of the upper eyelid is matching to another edge line from the lower eyelid. When the eye is blinking, both boundaries from those edge lines will move toward the other to finally meet somewhere. In the image above, the points A1 and B1 are meeting in a middle point named M. In real life, the blink doesn't happen on the middle point of their original position but let's make it easier for now.
The rig to achieve this is actually quite straightforward. The main thing is actually to model a NURBS sphere which has the same shape as the eye, including the bulge, and that will be constrained to the original eye. By using a NURBS surface, we've now got the ability to create some constraints to surface and drive them using some normalized U and V values. Just by playing with those values, we can have a bunch of deformers sliding on top of the eye shape. If we know the initial position of the points A1 and B1, which can be retrieved with a call to NurbsSurfaceMesh::GetClosestSurfacePosition(), then we can determine the U and V values of the mid point such as M( (A1.u + B1.u) / 2, (A1.v + B1.v) / 2 ). Pretty simple isn't it? Then if you need more deformers to have a better shape while deforming the points highlighted in red in the image above, you can retrieve the current U and V values of the point A1 and apply a coefficient according that will vary depending on the initial distance between the red point and A1.
So just by using an UV coordinate system, we can easily determine the position of our deformers on top of the eye shape. As the maths are really basic, it should be pretty straightforward to add some new features.
« previous entries - page 1 of 3