Both are 100% ICE based systems and it's not Hybride's policy to go
public with our tools. We did collaborate with Fabric Engine on CP
Flora. We wanted to use it on this project and we had a huge input into
it's design, but because of time constraints and lack of familiarity
with their code to quickly adjust it to our needs, we ended up going
back to a 100% ICE based tree solution for White House Down.
-Mathieu
On 05/07/2013 4:05 AM, Eugen Sares wrote:
Thanks for elaborating, Mathieu!
Another interesting point would be the city generator and your tree
system.
Did you build everything in Softimage from the ground up, or is there
a mixed pipeline behind all the assets you needed?
Do you plan to ever go public with those systems?
Am 03.07.2013 18:01, schrieb Mathieu Leclaire:
Hi Eugen,
>which version did you use, and how many seats?
>Any serious trouble you ran into?
You're talking about Fabric Engine' Creation Platform? We have a site
license so we can do deep image processing on about 120 machines if
we chose to. For Nuke, we have 20 or 25 licenses (I'm not sure
anymore). So by using our Creation Platform site licenses, we can use
many more machines to process the data without having to buy more
Nuke licenses. But the speed gain is not only because we can now use
more machines, our CP based deep image tool is much faster then Nuke,
though it's hard to say how much faster. It's relative to a lot of
factors and we are still working on optimizing our version. We've
noticed certain operations that can be over 10 times faster, while
others can be longer then Nuke, but we are still putting in a lot of
work and hope to improve performance even more as we learn to use CP
more and more. Creation Platform is a lot to take in so all the
trouble we ran into was mostly a normal part of the learning curve
that comes with adopting a new development platform. I don't remember
on which version we started implementing this tool, but we've adapted
with each new release of the platform.
>So you built your own crowd system... what's the reason for not
using the built-in system?
We created a crowd system for the French movie Jappeloup where we
delivered 404 crowd shots in about 3-4 months last summer. This
happened before Crowd FX was released. I remember having discussions
with Autodesk while they where still working on Crowd FX, but we had
to deliver shots way before their system was to be complete and
stable. Our crowd system isn't complex. There's no real interaction
between agents. It's a stadium agent based crowd system. It's based
on a list of animation clips doing various actions, and the system is
all instance based. The system basically randomly choses an animation
cycle with a few clever tools to help select the timing and
distribution. Since it's all instances, the memory needed is much
less then creating unique mesh per agent, but the more varied the
action of the agents are, the more memory it takes and it can
eventually become as memory heavy as having unique geometry per
agent. It was a matter of finding a good threshold where you have
enough variations in the cycles so you don't notice they are being
repeated, but not too much so it keeps memory low. Our agents are
also very high resolution compared to most crowd solutions where
agents are very low-resolution. That helps the look of the crowd a
lot. It adds a lot of detail to the crowds and really helps sell the
shots. With deep composting, we can raise the bar even further and
split our renders in many layers without ever having to worry about
where the agents of each layer fit in the crowd. The system of White
House Down is the evolution of that system. Since the shots have
constantly moving cameras and the crowds are motion blurred with
individual agents only visible for a limited number of frames, we
could deal the crowds as if they where stadium agents where the
stadium is basically the streets of Washington. It was only a matter
of adding animation cycles of people reacting to a helicopter passing
just over their heads.
-Mathieu
On 03/07/2013 2:44 AM, Eugen Sares wrote:
Thanks a lot for this, Mathieu!
Always nice to hear when Softimage is used on such high profile
titles. That prooves a lot technically, and it is good for the
spirit, too...
Autodesk wants to use this for advertising...
Also, what you say about Fabric Engine instead of Nuke is amazing.
If I may ask,
which version did you use, and how many seats?
Any serious trouble you ran into?
So you built your own crowd system... what's the reason for not
using the built-in system?
Am 02.07.2013 18:19, schrieb Mathieu Leclaire:
Hi guys,
I just wanted to share some information on the shots we did for
White House Down.
First off, there's an article in fxguide that explains a bit what
we did :
http://www.fxguide.com/featured/action-beats-6-scenes-from-white-house-down/
And here is some more details about how we did it :
We built upon our ICE based City Generator that we created for Spy
Kids 4. In SK4, all the buildings where basically a bunch of
instances (windows, wall, doors, etc.) put together using Softimage
ICE logic to build very generic buildings. ICE was also used to
create the streetscape, populate the city with props (lamp post,
traffic lights, garbage cans, bus stops, etc.), distribute static
trees and car traffic. Everything was instances so memory
consumption was very low and render times where minimal (20-30
minutes a frame in Mental Ray at the time). The city in Spy Kids 4
was very generic and the cameras where very high up in the sky so
we didn't care as much about having a lot of details and
interaction on the ground level and we didn't really need specific
and recognizable buildings either.
The challenge in White House Down was the fact that it was
Washington and we needed to recognize very specific landmarks so it
needed to be a lot less generic. The action also happens very close
to the ground so we needed to have a lot more detail on the ground
level and there needed to be a lot of interaction with the
helicopters that are passing by.
So we modeled a lot more specific assets to add more variation
(very specific buildings and recognizable landmarks, more props,
more vegetation, more cars, etc.). We updated our building
generator to allow more customizations. We updated our props and
cars distribution systems. They where all still ICE based
instances, but we added a lot more controls to allow our users to
easily manage such complex scenes. We had a system to automate the
texturing of cars and props based on rules so we could texture
thousands of assets very quickly. Everything was also converted to
Stand-Ins to keep our working scenes very light and leave the heavy
lifting to the renderer.
Which brings me to Arnold.
We knew the trick to making these shots as realistic as possible
would be to add as much details as we possibly could. Arnold is so
good at handling a lot of geometry and we where all very impressed
by how much Arnold could chew (we where managing somewhere around
500-600 million polygons at a time) but it still wasn't going to be
enough, so we built a deep image compositing pipeline for this
project to allowed us to add so much more detail to the shots.
Every asset where built in low and high resolution. So we basically
loaded whatever elements we where rendering in a layer as high
resolution while the rest of the scene assets where all low
resolution only to be visible through secondary rays (so to cast
reflections, shadows, GI, etc.). We could then combine all the
layers through deep compositing and could extract whatever layer we
desired without worrying about generating the proper hold-out
mattes at render time (which would have been impossible to manage
at that level of detail).
In one shot, we calculated that once all the layers where merged
together using our deep image pipeline, it added up to just over
4.2 billion polygons... though that number is not quite exact since
we always loaded all assets as lo-res in memory except for the
visible elements that where being rendered in high resolution. We
have a lot of low res geometry that is repeated in many layers, so
the exact number is slightly lower then the 4.2 billion polygons
reported, but still... we ended up managing a lot of data for that
show.
Render times where also very reasonable, varying from 20 minutes to
2-3 hours per frame rendered at 3K. Once we added all the layers in
one shot, then it came somewhere between 10-12 hours per frame.
We started out using Nuke to manipulate our deep images, but we
ended up creating an in-house custom standalone application using
Creation Platform from Fabric Engine to accelerate the deep image
manipulations. What took hours to manage in Nuke could now be done
in minutes and we could now also exploit our entire render farm to
extract the desired layers when needed.
Finally, the last layer of complexity came from the interaction
between the helicopters and the environment. We simulated and baked
rotor wash wind fields of air being pushed by those animated Black
Hawks using Exocortex Slipstream. That wind field then was used to
simulate dust, debris, tree deformations and crowd cloth
simulations. Since the trees needed to be simulated, we created a
custom ICE strand based tree system to deform the branches and
simulate the leaves movement from that wind field. Since the trees
where all strand based, they where very light to manage and render.
We also had created a custom ICE based crowd system for the movie
Jappeloup that was updated for this project. We bought a couple
Kinect to do in-house motion capture and build a list of animation
cycles of agents reacting to helicopters flying over their heads.
We then procedurally analyzed the movement of the helicopters per
shot and randomly select an animation cycle from the list and time
the cycle in a way that the agents would react when the helicopters
passed within a specified distance of the agents.
These where definitely the most complex and technically challenging
shots we ever managed here at Hybride. It was achievable thanks to
the evolution of a lot of in-house tools we had created over the
years and obviously, thanks to a lot of very talented and hard
working people in a very short span of 3-4 months.
Mathieu Leclaire
Head of R&D
Hybride Technologies, a Ubisoft division
