That’s right, folks! I’m coming this year!
I’ll make a quick, 3 day, stop in New York first, but then I’m all New Orleans! My plane is leaving tomorrow at 11:15am from Prague to JFK.
I’m especially looking forward to the digital workflow and pipeline presentations and products. Then I’m going after entertainment and advertising systems and, of course, Eyeonline’s and The Foundry’s new additions to the compositing mill. Maya 2010 migh also be fun.
So, anyways, if you’re going to visit Siggraph this year, stop by Cebas’ booth #3207 and say hi, or just enjoy the demos of finalRender we’ll be doing at the booth
It is sad, but the promising concept of Containers introduced in 3ds Max 2010 is lacking fundamental functionality. It’s lacking so much I can hardly see a benefit in using them instead of XRefs.
Yes! I’m finding Nuke more and more appealing. Especially the customization and general workflow parts. I’m really digging the whole channels paradigm as well as the Python integration, of course
I’m yet to script something more complex than a “dir(nuke)” or “print ‘test'” but I’ve managed to get some custom menus and toolbars out of the init scripts with the help of the documentation, which is great, by the way. I’ll also try to script custom Nuke comp scripts out of Nuke, say, via MAXScript, which shouldn’t be that complex. I’m thinking of writing out a simple pre-composite script after rendering is done, for example, which will generate not only the rendered images, but also a simple pre-made Nuke composition for the 2D artists to start with, with all the renders in it, maybe even put together. Just for the fun of it
I’ve given Toxik a spin and I’ve found it unusable for my particular needs (but that was kinda obvious almost from the very begining).
The cons were namely:
- Awkward user interface
- Strange and unfamiliar compositing paradigm
- Owned by Autodesk
- Dubious future
- Newly revamped compositing package from a dead end concept
- Seemed to be aimed at larger, primarily 2D, post-houses
While the pros were:
- Built-in revision and versioning system
- Built-in connection to Oracle database (perhaps other DBs were supported as well?)
- Collaborative compositing design
- Fresh, modern architecture with HDR and 32bit compositing in mind
- Python scripting
- Seemed very robust and fast
As I said, those pros or cons reflect my particular needs. While others might or might not agree with me, it’s their problem I found Toxik unusable for my needs and thus I ruled Toxik out of my pipeline development process.
As I’d mentioned, this year is a year of changes and expansion for me, so, naturally, I’m looking for ways of expanding my postproduction pipeline, namely, compositing. I’ve been using Eyeon’s Fusion for a few years now and I find it very powerful, fast and realiable. However, I’ve been looking into other areas as well.
While I own a copy of After Effects CS4, I don’t find it that flexible and suited for my particular needs. I certainly want to go the “node-based” way. Don’t get me wrong, After Effects is a great package with a huge userbase which means tons of plugins and tutorials are available for it, but, as I said, I don’t want to go this, linear, route. So, I have a few options that are within my financial reach: Fusion, Nuke or Toxik. I certailny don’t want to invest in a brand new product on the market with dubious future, especially when owned by Autodesk, which potentially rules out Toxik, however, I’ll see how well it plays with 3ds Max and Maya (downloading the trial as I’m typing). I’ve been using Fusion for some years and I love it, so that certainly makes it a hot candidate. However, I’m always open to new possibilities, better, smareter or quicker workflows. Basically, anything that helps to improve my work in any way, ultimately in quality, will be on my highest priorities list.
Great news, at least some, that came from the Autodesk aquisition of Softimage is that it plans to include CAT in the upcoming 3ds Max version (3ds Max 2010), which I consider being fantastic!
CAT will finally mean a lot of time and effort saved when dealing with character rigging, setup and animation. The layering system is fantastic as is the rig itself. I don’t know how far will Autodesk push the interoperability of the rig and MotionBuilder or Biped for example, but knowing Autodesk, that’ll most likely be up to us, the end users and TDs. I’m planning to base my complete character pipeline around CAT, of course, only under the single condition that CAT works the way it should! and tie everything up to MotionBuilder rigs, possibly Biped (but probably not as I don’t use Biped at all), and other modules and areas of 3ds Max. The next step will be interoperability with Maya, which’ll allow me to utilize Maya’s fantastic cMuscle and nCloth.
I have the tools pre-planned here mostly on paper. The overall pipeline will be revolved around XML and MySQL, as much open source as it gets. So the core, proprietary components that are CAT and other pieces will have to work perfectly in order for me to go into this venture. But the fact that every seat of 3ds Max 2010 will have CAT is a very solid and good foundation. I like this idea, it’ll definitely save me tons of work and time, which is crucial. It’s the one and only new feature I’m actually very excited about.
But, if all fails and Autodesk (again) proves itself incompetent, arogant and stupid, there’s always a fantastic solution from Kees Rijnen as he announced his amazing Puppetshop to be available for commercial use for free! He’s awesome!
In the mean time, get to know CAT and learn it in and out as that’s gonna become the one and primary solution for complex character animation work in the near future. I believe it, you should too!
People who’ve worked with me already know my attitude towards groups and why I always tell people who collaborate with me NOT to use them. But they never bother investigating why I tell them so. I agree that it is easy to condemn something right away, however, believe me, I have very good reasons for doing so.
The thing with groups in Max is that they are a special form of a hierarchy which isn’t transparent enough for a general user. They’re fast to create, but mainly, groups are a very convenient way for creating selection sets that are persistent (i.e. they get saved with the file) and you can return to them anytime you want and select a bunch of objects immediately just by clicking on any of the members in the group. These are all great advantages of gropus. The huge disadvantage is their transparency (by that I mean the way they work is hidden from the general user). A user can quickly and easily get carried away and make complex nested group assemblies which can become a REAL pain in the ass in the production pipeline if not taken care of properly. I personally don’t use groups at all (as you can easily substitute them for a different, pipeline friendly, workflow) and very strongly recommend anyone who shares files with me or any other member in our production environment, NOT using them as well.