Colorbleed: Eneco Hollandse Wind

Hey everyone,

Some time ago we worked on a CG papercraft animation for dutch power company Eneco.

Here’s the video:

Here’s the clients version on youtube (so it can be embedded here on tech-artist):


And a small making of:

We had only four weeks from start to finish for this project with a team of 6 people (of which were 3 interns).
And of course some more information about some technical bits:

The biggest hurdle: scene/asset sizes
One of the biggest challenges was the amount of moving geometry that we wanted to tweak (and be able to direct) in the animation scenes. We tested Maya’s gpuCache system which appeared to be working extremely well, the only issue was that it didn’t allow for offsetting the unwrapping animation. As opposed to many other Maya features the source code for the gpuCache is provided and extremely easy to go through (even though it’s a bit bulky). Since we’re under a tight deadline I took a Saturday night to see if I could implement offsetting gpuCaches without hurting the gpuCache’s primary benefit: extreme speed. Unexpectedly it took me little over an hour to implement time offsetting. Have a look at the making of and keep in mind that the animation’s that you see playing of the city (around 0:50 in the making of) are actual real-time recordings (not playblasts). In short, gpuCaches are awesome!

The next thing was being able to render this. We were using vray proxies. The vrayformaya 3.0 nightlies support alembics which we quickly tested, yet it didn’t provide us the workflow we wanted with gpuCaches (which are basicly optimized alembics). So I wrapped up a script that converted the gpuCaches into the related vrayProxies with the correct time offset. Then we stepped into one of the major vray issues with vrayProxies, which is the lack of optimization for offset. Vray will not optimize the loading of vrayProxies if it uses the same file with different time offsets. Therefore even if we have 30 proxy files, but they are in the scene thousands of times with offsets each instance will be individually loaded. We ended up with a file that would pre-load proxies for about 2 hours before it even started rendering, crazy!

So we had to produce a workaround to make it much faster, which was more of a game technique: Object Pooling. I reworked my script to convert the gpuCaches so that after a paper building is unwrapped it gets replaced by a new vrayProxy that has no offset at all and is considered static. This means that at any time it will only have to load separately the currently moving vrayProxy instances (instead of also the ones that aren’t build up yet). Also we keyed the visibilities nicely, yet it seemed our V-ray version had a bug with vrayProxies that it would also load invisible (and unused) vrayProxies in the scene. (I read in the changelog this is fixed in one of the latest 3.0 nightlies). We briefly tried to set the render hidden geometry dropdown menu to “NEVER”, yet this gave issues with some of our other alembics in the scene.

From unmanageable scenes we got to a workflow that made it easy to tweak the animations and relatively light-weight to render.

Paper unfolding
Of course another technical bit was the unfolding of paper. At first I prototyped a custom deformer implementation that would automatically unfold a mesh from a starting face along it’s connected faces. (Also tested with automatic cutting of faces based on dijkstra’s algorithm to figure out the shortest path). By making it a deformer it would behave somewhat non-destructive so the idea was we could tweak the models and quickly preview how it would unfold. Even though the idea sounds great the overall prototype never gave enough freedom to really direct and customize how the object would unfold. Things like timing or simplifying the look of the unfold were near impossible.

Because of the tight deadline we had to take a step back and chose for the brute force way of joint-based setups. Of course with the necessary optimizations using a quick toolset I pushed together to ensure creating the rigs went flawless. Then we had a set of animation tools that made it easy for animators to focus on the timing of the unfolds by automating the follow-through/overshoot workflow.

Let me know what you like/dislike of the project.
Also I’m very curious to hear whether the technical bits I laid out here are actually of any interest to you all. If not I could skip that part next time. :slight_smile:


Great ad! Really like the tech break downs as well. Nice to see a post mortem on other projects:) thanks for sharing