Btw, CP Flora has been used for some shots done in the trailer :). But as Mathieu said, we finally switch to a 100% ICE based system that could give more realistic results on the shape of the trees. It could generate a simulated tree from a polygon mesh model, so the control on the look could be total. To finish, Mathieu is too modest to say that the ICE based tree system was its own design and implementation. I'm still amazed on things you can do with an ICE tree ... if you know your stuff ;).
Cheers, Guillaume On Fri, Jul 5, 2013 at 5:21 PM, Mathieu Leclaire <mlecl...@hybride.com>wrote: > 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/<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 >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
