It's every bit as painful as it was when I installed it on my old desktop machine.  Maybe a liiiiiittle bit better since at there's a configure for it now, but installing prebuilt binaries really spoils you.

If you've never installed a traditional unix/linux/macosx application,  you're in for a treat. It's one thing if it's your own application, as well, since you'll know what's going on: but when it's someone else's...

Well, you never *really* know what any application installer is doing.  Data gets socked away hither and thither, but mostly you don't know about it.

Doing a configure/make/make install sequence usually displays TONS of data.  There will be a thousand lines of successful completions, another thousand of warnings of varying severity (with usually alarming-sounding messages that may or may not be important - and very frequently aren't), and maybe even a few outright failures that *also* may or may not be important.

A truly great build will usually ease your mind a little.  Several of the warnings you get for things like boost::python will reassure you that the error you're seeing happens to nearly everyone and shouldn't alarm you.

Somehow, that doesn't make me feel entirely at ease. It's like your girlfriend telling you, "It's ok, honey. It could happen to anyone."

Then there are errors like this:
Please ensure that LDFLAGS is configured properly, or specify --with-boost-root

Thanks.  I'll do that.

The point was that wasn't a positive statement...

But it got me thinking: there's been so much talk about how video games will become as good as movies - and it's a pet peeve of mine that writers can be so ignorant.

What??? You say?

Sure.  Video games will eventually look as good as what you see when you go to see Hellboy this weekend.

But when that happens, movies won't look like that any more.

Now eventually, and we're not talking in the next year or two, we're talking a decade down the road perhaps, video games will start to look a lot like what you see when you walk outside (except of course that there will be zombies or terminators in the video game and may or may not be killer cyborgs and diseased undead prowling your real-life neighborhood).  By then, feature films may well be predominantly 3d - but your video games probably won't be.  Another five or ten years and then maybe the playing field will be levelled.  Except that the movie theaters will have vibrating chairs, a better sound system than you're likely to have at home, misters and blowers and scent generators, actuators to lift and tilt the chairs.  Oh - and even better 3d and higher res displays than consumer televisions can deliver (what, you thought HD was the best it got?  Please.  Not even today.  But don't count on a 4k home television standard any time soon.)

Oh, and their screens will always be bigger than yours.

The constant talk about video games 'replacing' movies on some level just sounds like people talking 100 years ago about radio replacing books.  The internet hasn't even replaced books - though it has put printed encyclopedias out of business, but then how many people ever kept a consistently updated set of encyclopedias in their homes?  If you ever even owned a set, chances are you owned one that still talked about the USSR and the apartheid government of South Africa.  If the internet replaced *that* bookshelf dominating monstrosity, I'd say that's not even surprising.  Public libraries had been replacing private encyclopedias for decades already.

Ubisoft's purchase of Hybride is motivated by the same thing that's making companies like Digital Domain say they want to get into video game production: fear. The fear that they won't be prepared if things go that way.  The fear they're going to be missing out on something.  They see something like the release of the new GTA and it looks like video games are the road to making billions.  It's just not true, any more than a small multimedia house in New Orleans should look to Wall•E as the future of their company.  Ubisoft doesn't need Hybride to understand how to make better CG. And the guys at Hybride probably can't help much with getting their ideas into the game engine: because that's an entirely different discipline.

My point is, video games will change.  But I don't think they'll "converge" with feature films any more than television "converged" with feature films.  Television is still a poor substitute for going to the movies and as much as we make the decision to sometimes catch something when it comes out on television/pay-per-view/dvd/bluray/what-have-you, as a society the rise of television has done nothing to diminish movie attendance.  Now we just expect more entertainment, and predominantly entertainment that we can enjoy just by sitting on our ass with a bucket of popcorn in our lap or a plate of nachos on the coffee table and no video game controller anywhere in site.  A theater full of people aren't going to be strumming their Guitar Hero guitars or thrashing around with their Wii controllers, and next year's Batman installment isn't going to require you to learn to drive the batmobile.

Unless of course you want to.

I use Boujou for matchmoving but am tracking 640x480 camera resolution all of the time... I often have shots with handheld very shaky camera and motion blur. Boujou has trouble tracking it. Is it just that there's to much blur/shakiness or would a higher camera resolution help?

and my response:

Well, it looks like there are a number of issues to overcome:

First, the quality of the footage: handheld/shaky/moblurred footage is just awful to work with. If you're just the artist, ie, you get what's handed to you: you work with what you have. There's no telling Mann, Fincher or Stone they have to reshoot because your job is hard. Their job is harder and it's them the client paid for, not you. If it's for your own projects, ie, you're the director or at least the vfx supervisor on a smaller project: you have to take this into your hands (so to speak) and fix it before it gets past the camera! Since you're working with 640x480 footage, I have to assume you can address it at this stage: these are obviously personal projects, not features or broadcast. Fix the source first! Don't shoot/allow to be shot footage that's going to suck to do post on!

Second, the resolution of the footage: Until you've worked in HD or film res, it's hard to appreciate just how much easier it is to work with on a tracking level. A dot that is so small it'll disappear into noise at NTSC is an obvious crosshair at 2k. Smudges on the wall and skin blemishes become usable tracking points. If you have the option to work with higher resolution footage, insist on it!

Third: Lighting. Again, this is only something you can influence if you're shooting your own projects, but remember to light for contrast not final levels. More light means faster shutter speeds means less motion blur. Light for the type of shadows you want, not how dark you want the scene when you're shooting for visual effects. If your key and fills are set properly, you can always make the shot darker when grading. This isn't as much of an issue when shooting film or deep color digital like the Arri Digital cameras since their shadow detail is good enough to boost for tracking detail. But if you're shooting with consumer or prosumer cameras, you've got jack but noise in the shadows and the low light levels will mean excessive blur and bad noise overall.

Fourth: Manual vs Auto. Boujou has a reputation as being the fire-and-forget solution for people that don't understand tracking. The really hard shots are going to need manual solutions. I don't mean hand-keyed (necessarily) but we're talking careful selection of usable tracking detail and improved setting of constraints. Personally, I recommend SynthEyes - unbelievably good price point and an unbeaten feature set. I know there are shots that people say they can click a button and get a solve on in Boujou that they can't get in SynthEyes, but the reverse is true far more often than it's not. When the footage is hard to work with, throw away the automatic solutions. Give them one run at it if you've got the time and processor power to spare, then move to something where you have some control.

Fifth: Tracking techniques. Track the center, not the edges. When doing a supervised track of moblurred features, follow the center of those blurs.

Sixth: Rendering techniques. Moblurred footage is hard to render to match because what you have to match is a particular slice of time. Think of it this way: you're placing tracking points on each frame, generally spaced apart at the rate of 24, 25 or 30 frames per second. Between frame 1 and frame 2, there's a fraction of a second where anything could happen. The camera could jump up a couple centimeters and back down for instance, before hitting frame 2. This will show in the motion blur but not in the keyframes. You can't easily fix for this! (See tip 1). More often, though, the problem is the phase of the render. How to address this will depend on your renderer. You may be able to adjust this in the renderer, you may have to adjust it in the actual animation keyframes depending on what 3d software you're working from. Basically, you need control of the shutter timing and shutter offset: when in that frame it opens and how long it stays open.

For high end vs. low end facilities, #6 can often be the difference between them. For all the skill you can buy from freelancers in tracking, modeling, animation, textures, etc: having the resources to do test renders and tweak that setting (and having someone on staff who can make sure you're addressing this) makes all the difference.

photo credit: Capture Queen ™

We really feel that this project is going to move mountains though, and change the way people view the real world around them, not just when they're in front of a computer.

The tendency towards developing for the iPhone is that the iPhone has arguably the best SDK there is: and a substantial and rapidly growing marketshare. Still, though, that limits our deployment: it's the largest selling smartphone-style device, but it doesn't represent the majority of the market. No-one does.

Today I've been evaluating Mojax, a cross-platform mobile development environment. It looks promising. It promises cross-platform compatibility, including access to a number of necessary core services like GPS, and currently runs on all phones supporting J2ME (Java on Mobile), all color Blackberry phones, and shortly Windows Mobile devices from WinMo 2003 onward, any mobile running Brew V2 or later, and Helio devices. Just the J2ME support gets me onto most smartphones - so this effectively would get the product onto every mobile device there is with gps capability.

This excites me because I like the prospect of running the application on every feature-capable mobile phone without having to separately develop for Blackberry, HTC, Samsung, and Nokia. Getting the product out simultaneously for iPhone, Windows Mobile, PalmOS and Blackberry would be fantastic. There are some annoyances with using J2ME midlets, but I'll take the slight user experience tradeoff for being able to deliver an application at all without breaking the bank

I've been designing the site to automatically rescale for my mobile phone, but I need a way to determine if I'm looking at it on the phone or on a desktop - and since my mobile browser is generally configured to identify as a desktop browser (so that I don't get sent to the "mobile version" of the sites I visit) it's harder to do. My browser does a great job of rendering full-screen pages and scaling them - if you've seen the iPhone browser, both Opera Mini and Pixsel do something similar though without 'multi-touch'.

That said, there's something to be said for designing a website that will gracefully scale when it's on a phone.

But when the browser identifies itself as a desktop browser, what's left? Javascript can pick up the screen size, but what about PHP? All my pages are created in PHP...

(more...)

If you've seen Indiana Jones and the Kingdom of the Crystal Skull in theaters this weekend, then I'm certain you've seen the first trailer for David Fincher's The Curious Case of Benjamin Button. You might remember seeing a rather weird trailer with Brad Pitt and Cate Blanchett and no dialogue but with beautifully melancholic music - that was the Benjamin Button trailer. Remarkably it's not online yet, so I can't exactly show it to everyone, but I can say that is absolutely phenomenal. I was not expecting it when I went in to midnight showing of Crystal Skull a few nights ago, but I was astounded at what I saw. I've got to start talking about this now, I can't constrain myself, because this trailer looked downright amazing, so much so, that I'm already claiming this is next year's Best Picture.
- FirstShowing.net

It's not often that a movie that's neither a remake nor a sequel creates such a staggering worldwide buzz within days of the appearance of its trailer (and only in theaters!  Except for a Spanish bootleg, there's still nothing online).  But just as I'd said weeks ago when I first saw the edit (when there was still bluescreen and placeholders for some scenes and we were watching versions of it with various pieces of temp music): the freakin' *trailer* gave me a lump in my throat.

Apparently it's not just because I was emotionally connected to it.  I've seen several bloggers say that they've gone back to their local theater 4-5 times SINCE THURSDAY NIGHT just to see this trailer again.  With words like "phenomenal", "masterpiece", "extraordinary" and people already insisting this will be the next year's shoo-in for the "Best Picture" Oscar, and finding that others have commented months back that just reading the script made them cry, I think I'm working on a great, great film.

DD's work looks great (I've seen a good bit more than is visible on the trailer, now, and I'll leave it to the future to reveal exactly what they're doing on it since I have yet to see any mention of it in the press) and I'm proud as hell of what we've been doing at Asylum.

It was good to come home today after a really long day  (I was on set for something else today from 7am to 10pm) and check the internet for the trailer and comments which I'd heard were appearing.  When you're doing something you love, have the respect of your peers, and get to work around people you actually look up to: it's a pretty nice way to live your life.  If I ever start aging backwards, like our dear friend Mr. Button, remind me to start doing this sooner.

"Through these collective efforts, a harmonized master list of titles has been created that should be useful as a touchstone for all effects stakeholders," says VES Exec Director, Eric Roth. "We think it represents a major step forward for our craft in standardizing the use of titles in the credits process for effects artists."

Of course, I'll interject here that if the Visual Effects Society actually carried any weight, someone would care. I'll further interject that if they'd actually attached descriptions to these titles it would mean a bit more - but since a good chunk of these are too nonspecific to mean anything (or at least vague enough to get people to fight over them) they've basically left us where we were before. (Except that since my responsibilities shift and sway on a regular basis, I can dig through the list for suggestions of what I should be calling myself - like this weekend, I think I'm calling myself the Visual Effects Photographer)

Questions regarding these guidelines can be addressed by calling the VES at 818-981-7861. Credits/Titles to be submitted in accordance with VES Guidelines follow after the cut:
(more...)

Since my earlier blog about normals-based relighting of rendered cg elements (something that can obviously be done in the original CG software if time allowed), I'd written a short piece on relighting real-world footage. Since then, I expanded on it slightly and now I've put it up on YouTube as a quick technique video.

A detailed video covering the normals-based relighting process is located here.

My friend marveled at how nice it would be if one day, a couple years from now, everything was able to talk that smoothly: that a character animated in Maya could be pulled into Houdini, for instance, as something other than an OBJ sequence or a separately rigged character that you had to tediously (or with a lot of specific coding) link to exported channel data.

I wonder if that interoperability thing will ever extend beyond each individual studio's implementation. Everybody has a way of getting software to talk amongst themselves, some solutions being more elegant than others, but when you invest in creating something as elaborate as this it becomes your own proprietary tool. If you develop a tool that an animator can take an animated character with a complex rig on it, arbitrarily select additional elements that were never *really* meant to be animated and animate them anyway, and the modeling team can modify the model and issue a new version of it - and the animation gets seamlessly transferred over to the new model, even able to be read into RealFlow, substituting a different set of low poly independent objects that are driven by the data in that XML file: you don't put that pipeline tool on the internet for everyone to download for free.

That tool becomes your secret weapon. As a studio with an investment in a powerful and unique proprietary tool, even charging for it may not mean as much to you as the edge you gain during the heat of production.

Being XML based and implemented in Python does put my current project a wee bit closer to being an open standard, though. Even Shake will take Python scripts now - and they're really powerful in it and getting more so as development continues. The readability thing for XML is a gigantic plus, and the way it represents data is great. I can build a module that will write out the translation of a locator in both world and local space, as a baked set (every frame has a value) and as a set of keyframes (values only for those frames where the value was explicitly set by the artist), as well as screenspace UV values - so the same XML file could reconstruct a scene for a lighter to light and render from or another animator to tweak the animation curves, or for RealFlow to drive low-poly proxy objects with to disturb a drifting mist, or for a compositor in Toxic to link an effect to. And it's all one XML file - not a half dozen formats (often multiple versions of each) and a hundred-unit sequence of geometry exports.

Hi!  I haven't been updating the vfx blog because I've been crazy busy.  Work has me deep in MEL and Python code most of the day, writing software to manage animation data, shuttle it this way and that and process it in interesting ways.  There's also the secret project that everyone isn't talking about but is quietly and excitedly waiting for (assuming they have any idea what it is).   We're on super-special-secret-lockdown at work, I'm guessing for the rest of the month.  I can scarcely go to the bathroom or grab a soda without passing through at least two security doors now.

Ok, I admit it, we've been contracted to create the lost tapes of the lunar landing.  Seems NASA has gotten enough flack about the original landing with people claiming they can prove it wasn't real that they've decided to create more proof to put the concerns to rest.

Or at least that's my amusing cover story until I'm allowed to talk about the other thing.

Between all the other little tasks, I'm in the process of working up a new tool for moving complex animation data around the pipeline.  The idea is to be able to read and write an XML file that contains as much data as anyone would care to put onto a model.  The model can be updated, have new elements added to or removed from it, all sorts of parts of that model can be animated at a whim by the artist and passed along to subsequent versions of the model, low res or high res versions, keeping all of the data intact, allowing for scaling of the animation data if it's transferred to a different model entirely, even passing along worldspace location and orientation of parts of the model (and maybe even eventually the full animation) to other platforms like Houdini and Realflow.

It's a little important for what we're doing on The Curious Case of Benjamin Button, but the existing tools I developed are working ok there (even if they're still a little limited and occasionally awkward - they're getting better on a weekly basis).  There's already a small test of what I'm doing in a broader sense: we have a particular element with a moderately complex rig on it that I'm publishing and subscribing the animation data on.

The Big Goal for this tool will be on T4 which we should be working on soon.  That'll be a huge show and we've got some really epic-scale work on it: most likely we'll be needing the more sophisticated animation tools for managing our data throughout the pipeline - so that's what I constantly keep in the back of my mind as I script the current version of the tools.  They need to serve the current project in the most complete way possible, and they need to be able to expand to do more than I'd currently dream of asking them to do.

It's a lesson that's come up recently because of a little tool I wrote that I've mentioned here before "CurveBaby" - CurveBaby allows me to take a scene with an animated camera and one or more animated objects, preserve the camera's relationship to one of those objects but change that object's animation - or, conversely, reanimate the camera and have the animation of the object automatically adjust to still look the same from the camera.  It's a powerful tool, and one that I can barely imagine how I'd get through half a day without using it at least once.

Big tools make big projects go a lot more smoothly.