EddieOffermann dot com

So I'm working on a side project that's mainly just for me, but it's so damn handy I might just make it publicly available when it's done (probably for a small monthly fee). It's basically a super quick way to run certain types of scan for stocks during the day, picking out data that's usually hard to get until the end of the day. I'm tying it into the OptionsXpress API so that when I identify a good entry or exit point on a stock, I can change my position with the click of a button.

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 »

and it's not even in the theater yet - but the trailer is.

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.

So this week, the Visual Effects Society (VES) published the first ever set of guidelines for titles in the visual effects industry. They assure us that Many Very Important People have looked over the list and given it the thumbs up.

"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 »

I know I sound like a broken record to some, but I had this footage sitting on my workstation and didn't want it to go to waste.

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.

I was talking to a friend today about what I'm doing with regards to managing data through an animation pipeline using XML. The more I work with it and the farther I get into the project, the more flexible and powerful the whole thing seems. Of course the goal to doing the implementation in Python is that virtually every software package in the vfx industry is python-friendly - so once the core routines are written, everything from Nuke and pyShake (the python plugin for Shake - if you haven't seen it yet, check it out here) to Maya, Houdini and RealFlow will be able to make use of them. I think most places are doing that these days, with a few nods to TCL/tk here and there - but broadly supported scripting languages are King and open description formats like XML are Queen.

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.

I don't know where I read that, but it amused me and stuck in my head.

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.

A few weeks ago, I posted a video covering the process of relighting rendered CG elements in a compositing tool like Shake using a surface normals pass.

Since that covered normals-based relighting of rendered cg elements, I thought I'd write an article that takes the concept a little farther and should stretch the reader's mind on what's possible with this sort of approach.

The earlier tutorial covered something that naturally can be accomplished by going back to the original scene in your 3d application, adjusting lighting and re-rendering: but I think there are times when we want to adjust the lighting primarily in the compositing application but want more than some masked-off gamma correction, lifts and crushes. So it's handy, then, to be able to apply an effect more similar to real-world lighting and that's what a rendered surface normals pass will enable us to do.

But what about real world imagery? Can this same technique be applied to live action footage just as it can be on a CG element?

Absolutely!

You'll want to start with a few elements like the following:

A full-color image like the above picture of a farmhouse. Under ideal conditions, you'd have an image with very diffuse lighting: something with a lot of bounce light or an exterior on an overcast day. The idea here is that there are relatively few real shadows in the image. The reality is that you won't have that very often and you'll have to use what you've got. You may decide that the shadows that do exist need to be painted out before you continue. I haven't done that for this example, but you'd be hard pressed to find a high end effects project that relit a real world environment and didn't remove the existing shadows at some point in the pipeline.

The above image is a matte of the farmhouse pictured above. You'll probably need to generate something like this for your scene if you haven't already.

A surface normals pass of a polysphere with its shading set to be as unsmooth as possible. I prefer this because I have a better feeling of where these surfaces are facing than I do straight from a sphere. It makes it like a special kind of color palette so I can perform the next step:

Next, I roto out a super-simple normal map of the surface in the image. This can be more or less complicated, depending on how much detail you want in the relight. If the surfaces are softer, you may want to blur the resulting image some: this will soften the transitions. Pick colors for each of your surfaces from the faces of the polysphere normal pass, making sure to keep parallel faces the same color as you interactively create a normal pass for your real-world element.

Then, I set up the OpaqueWhite OneLight Plus node as described in the normals relighting video here. Shake users can download the tool for free here.

It'll look similar to this:

Over on the right, you see where I've created the interactive surface normals pass. Those are groups with a few quickshapes and Mult nodes layered to create the interactive normals. In this case, since I didn't build out the ground and the barn next to the farmhouse, I chose to use the alpha from the interactive normals as the matte for the OW_OneLight+ node instead of the matte extraction I showed above. A smoothly blended surface for the ground, and a couple blurred normal shapes for the trees could make this quite convincing.

On the left, the fade leading into the over and the mix node to mix the whole thing back together is just one way of tweaking the levels of relighting that you're doing.

I posted a really short render of the light source moving across so that you can get an idea of what can be done. I kept it fairly subtle, and keep in mind that a little more work to create normals data for the ground, barn and trees would be required for a real project.

1. Build 3d geometry to match the visible elements
2. matchmove that geometry to match the footage
3. render a surface normals pass of those elements
4. use that rendered surface normals pass to relight the live footage.

In a future installment, I'll describe a method to generate surface-normals data by painting a bump map onto an image. In the meantime, I'll leave it as an exercise to the curious reader: how could you convert a simple greyscale height map into surface normals data in Shake?

I noticed the other day that my own 2d crowd generation software tool (DynaCyc) is ranking higher on google than Massive Software's listing for their incredible 3d crowd sim software.

In fact, if you google "Crowd Generation" there are two hits for my own websites before theirs comes up.

While DynaCyc is nowhere near as sophisticated for generating realistic behavior (it's more of a dynamic matte painting tool than a crowd generator - I created it for doing plants and trees to algorithmically make forests and such), it's pretty cool that I'm placing so well.

I really need to get the tutorial for my uv remapping tool recorded so that people can start using it. At the moment, though, I'm working 12-14 hrs a day, 6 days a week scripting some fancy animation pipeline tools.

The funny bit is something I've come to realize of the last couple days: while I fully grasp the minutiae of what I do, some of what I'm doing just baffles me in the big picture. I wrote a tool for "recasting" an animation from one space to another. For instance, if there's an object in a shot done during previs, and that original object has a particular animation on it, and there's a camera with a camera angle that we like... but the object itself is given a different animation in our scene because it has to fit in the "world" relative to other objects and be moving at a certain speed, reach a certain place at a certain time... I can take the camera motion from the original animation and transform it to the new shot maintaining the relationship between the camera and the element... while replacing that element's animation.

That's tricky... but I know how to make it happen and I've embodied it in a deceptively simple tool.

Separately, I worked out a method for stitching multiple animated shots containing a common object and many separate cameras together. The object's motion remains constant, and the cameras follow it along the path. Additionally, I developed a method for steering that element so that I can change its motion, adjusting the cameras to follow it.

That last one works using the first tool... so they end up all being connected to each other.

Once that happens, it feels like magic. I no longer understand the big picture: how we now have nearly a hundred separate shots stitched seamlessly together, but with different animation... and still working with the cameras and tracked objects matching to the footage? That starts to get away from me... I can conceptualize it as steps, as stages to reach a goal... I can break it down into its component parts: but the whole big process I understand only in that way: as big steps. I don't hold the whole thing in my head at once, though I use the tools that make it happen several times a day.

What's also funny is how much I'm even animating at this point... and I'm no animator, believe me. Let me write you a few expressions, though, and I can sometimes fake it.

I am officially in crunch...

It's mini-crunch, though, because we're just working to get things together for the trailer. Most of the staff isn't actually working overtime, but there's a few of us... the dynamics/fluid guys, an animator or two, the cg supe and me, piecing together the necessary bits to get the shots ready for the trailer.

I wish I could be a little more clear on what exactly it is I'm doing... When the trailer comes out in a couple weeks I can at least indicate then what segment of the film I'm addressing - I'd rather leave that part as a surprise for when the trailer hits (not to mention that talking about things like that would get me in hot water).

In a sufficiently vague sort of way, I can say that there's a segment I'm working on right now that's around 76 shots long, each ranging from 50-300 frames, that has a common element that's travelling between them. Our tracking team has been tracking that element, and its progress through each individual scene, for each of those 76 shots (and at least that many more as well that I'm not dealing with yet).

The particular task I've been working on is basically a continuity script. It's a MEL script that gathers all of that data: cameras, animated and matchmoved elements, and stitches them together end to end in a master shot. This way, the element that's moving through the scene will maintain an accurate location relative to the CG environment.

To coincide with what's happening in each shot, it's necessary on that big grandaddy master shot to make adjustments: turn something here, nudge something there... and that affects the path of that common element throughout all of the individual shots.

Do you see where I'm going with this?

Basically, if we imagine that I'm talking about a man driving a car across the salt flats in Utah (not at all what's happening in this film), there are features on the horizon that we want to be consistently and realistically moving in relation to the view of the car. If the driver swerves to miss a rock, we want to change the path he's taking across the salt flats (even though in the original plates, that driver would have been sitting in a stationary vehicle in front of a bluescreen, with some hydraulics underneath making the car tilt and sway to add realism). Our view of the car from the camera should stay the same... Car and camera must maintain their relationship... but the position, speed, orientation, etc of the car and camera combined will need to change. If there's a guy on one of those sail-carts out there, we need to make sure his path is realistic and that he's in the right place in the background of each shot...

Remember that the car, the driver, and the camera are often the only real things here... the sail-cart, other things on the horizon, in fact the entire salt flats... all are cg or augmented with cg.

So I've been developing tools for funneling data from all of these shots... everything from camera data to object matchmoves, world-space offsets for each shot, and animation data... stringing it together into a seamless master scene, manipulating the paths and locations of elements in that master scene and transferring that data back into the individual shots. If we need our hypothetical salt-flats driver to swerve this way and that across several separate shots, I'm making sure that it doesn't just "kinda look right" but that we can get that data integrated into the object and camera motion of several live camera plates.

If somebody didn't ask me if I could do it, I'd probably have never thought it could even be done.

If I'm kinda scarce around here in blogland, it's because I'm catching a much-needed nap in between long shifts.

I just commented this to a thread on a film where there has been rampant speculation about the casting of a particular character. This character is generally thought to be of a particular ethnicity, and there's been a lot of discussion over who will be cast in the role. Popularly, people seem to be hoping it will be of the same ethnicity as they believe the character to be... but when we're talking about someone of Mediterranean/Arab/North African/Middle Eastern ethnicity - it's sometimes hard to find the right one. If the character was originally Pakistani, do you really have to find a Pakistani to play them? Or is it ok to get someone from Afghanistan or India? Is it racist to cast an Italian-American? or is it racist to say that you *can't* cast one?

Ultimately, I deleted my comment there. In reality, it's like that old (and not very PC) maxim: Arguing on the internet is like competing in the special olympics. Even if you win, you're still retarded.

This particular comment was on an upcoming movie version of a video game. I decided to reproduce it here to let everyone know that I haven't died. I was just sick most of last week and while I soldiered through work every day, I basically came home and slept - so my effects blog suffered. The original poster had ranted about the casting of Jesus in The Passion of the Christ, the Spartans in 300, and various other distant historical characters in what he felt were ethnically inaccurate ways. Here was my response:

The original character back in 1989 was a stack of animated pixels about a hundred raster lines tall. As I recall, there was nothing about that tiny sprite animation that suggested any sort of ethnicity. It was Mario Brothers set in a middle eastern palace - so let's not make it out that the casting in a feature film version of a video game franchise is making any sort of political/social statement. With any luck, it'll be a great, fun movie: one we'll all enjoy, one that will be chock-full of fun stunts, visual effects and a good Action-Adventure storyline.

You write like you think the Greeks of 2500 years ago bear more than a passing ethnic similarity to people who live in Greece now, or that anyone has the foggiest idea if Jesus looked like a modern Mediterranean or an African. It's been a long time... I'm not sure we even know what *anybody* looked like back then. Casting a modern Israeli is just as irrelevant as casting a white man.

I feel like this sentence:

It is about people of a particular ethnicity not feeling like they can connect to a character in a movie unless they are the same 'ethnicity' or 'race' as them.

is as validly pointed at you as it is to anyone else.

Hollywood is all about makebelieve. When Bollywood makes a film, they cast predominantly Indian actors - because that's what their audience wants to see. It's not that the studio execs are racist, or even that Indian viewing audiences hate white people... It's that yes, for the most part audiences *do* connect to characters that are as much like them as possible. Movies aimed at a female audience have lots of female characters... Movies aimed at children usually have a bunch of kids in them. Movies aimed at white people are likely to have lots of white people in them too. Same with anything from Tyler Perry or Martin Lawrence - movies targeted at black audiences have lots of black people in them... and when I went to see "The Bucket List" guess what? Half the theater was in their declining years. Think we'd have brought out all those retirees to the theater if it was about a couple 20-year-olds dying of Hepatitis? Because I sure don't, and I don't think it's because grandpa hates his grandkids.

I really dislike that we're not a lot more accepting of differences of all kinds: race, gender, ethnic diversity within races, age, sexuality... but not everything that a particular group is interested in is racist, sexist, homophobic or what-have-you. And not everything that's marketed to one of these groups is symptomatic of some gigantic social ill.