This video is part of our current efforts to port our old aging Minecraft animations to the new BLender Engine Eevee.
This allows us to speed up our workflow and will enable us to make better Minecraft animations in less time.

The Story behind this video:

If you follow our CGI YouTube channel since it’s early days you might already have seen one or more of our Minecraft animations.
You might also noticed that we did our last one in 2014 and since then it became very quiet around them.
This does not meant we’ve given up on those animations!
In fact we’ve been working on new upcoming videos ever since.

The above video is part of an upcoming project we were working on in request for RedBlueAlex99 an English Let’s Player on YouTube.
Unfortunately the initial project never got finished nor released.
A few previews and partial renders are available and we’ll share the old Prototypes with you soon.

In the past we did other Minecraft themed projects on his request like the Transformers Intro video btw.

The issues we faced:

To start the story behind this video I like to cover the issues we faced.

One of many reasons is that all our Minecraft animations were made in an old and aging engine. Namely Blender Internal.
While it is very well possible to deliver good looking visuals using this engine it is also extremely slow. Even slower on the hardware we’ve had back then.
Which made rendering those animations took very long (aprox. 3h per frame)
For a 1 minute animations on 25 fps this would result in 7,5 days render time. But only if we’ve ran the render machine 24/7
As you might already have noticed our animations are often longer and not rendered in one run.

In reality this rarely happens if you do not have dedicated hardware just for rendering which was something I did not had.

The problem with animations is you often find issues or get better ideas during the render.
In case of issues you stop the render, fix it and re schedule the affected frames.
Depending on the issue this could be only a few frames or half of the animation.

Furthermore our animations became more and more complex, detailed and over all better.
Which also introduces longer render times and especially sky rockets the RAM usage.
Being already short on hardware this was one of the biggest concerns.

The last breath of Blender Internal:

Another issue which added up to the already bad overall situation was the release of Blender 2.80 on the 30th July 2019.
This was a huge turning point in the history of Blender in many regards.
But most noticeably for us the removal of the Blender Internal engine.
Thank fully they also added Eevee along side this which is our live saver here.

So we where either limited to Blender 2.79 or needed to port all our Minecraft projects to Cycles or Eevee.
Unfortunately the Blender Internal shaders where not compatible with the node system Cycles and Eevee use.

Why did we not ported to Cycles earlier?

There were multiple reasons why we did not do this.

First of all Cycles would not have solved our render time and RAM issue. In fact it would have gotten worse due to the way Cycles works internally.
Being a photo realistic path tracing engine Cycles takes samples for each pixel in the final image.
Doing so it determines a ray shooting through the scene where the pixel is the origin.
It then traces it through the entire scene to determine it’s final color.
The side effect is a nosy image if you set the sample value too low.

In order to get then s less nosy good looking images a high sample count is needed which sky rockets the render time.
Unfortunate Cycles did not offered a de-noising algorithm to smooth the final image for a long time.

The absence of a good network render

To over come render time issues you usually have dedicated computers solely for the purpose to render your frames.
Those are often called render farms.
Which essentially is a set of render nodes manged by a server to distribute the workload and receiving the final images.

Blender does not have such a thing by default. Well at least the one it once offered which was also dropped was very unreliable.
So Cycles with it’s increased render load was not to handle very easily but this was also an issue we already faced with Blender internal.

At the end we’ve ended up distributing the work manually.
Login into each machine.
Tell it which frames to render.
Manually transferring the final images for the post processing.

This also had a huge impact on our workload and consumed a lot of time.
Since it was not rare the case we did estimate the required render time by a client incorrectly we also wasted a lot of precious time.

Parallelism

Since an average computer has a CPU and GPU it seems to be obvious to render animations on both at the same time.
Unfortunate Cycles did for a long time also not suppored this either.
This way we would, and did on other projects, ending up to open up two instances of Blender just to render on CPU and GPU in parallel.
As you can imagine this will double the RAM usage.

Being still short on hardware and the increasing complexity of our Minecraft animations this was not an option for those.

It gotten better!

Meanwhile the situation did get a lot better till today.

• Cycles supports parallel rendering on CPU and GPU on one single machine.
• Our hardware was upgraded
• And thanks to crowd render we have our own little render farm now

What’s the deal with Eevee then?

Eevee is a real time render engine similar to what the Unreal Engine or Unity offers. Or even the Source Film Maker.

It runs on top of GLSL and feature PBR shaders and most importantly it is „real time“!
Well actually real time is to put into quotes because in fact Eevee takes still a few seconds to compose the final image.
But a few seconds (up to 20) are a huge deal compared to still multiple minutes on our Farm.

Further more I feel like the renders done with Eevee look a lot better as the old once we did in Blender internal.
To be fair multiple years have passed and I learned a lot about CGI and Blender in the meantime.

The best thing about Eevee is that it shares the same shader node system as like Cycles.
This means you can switch both render engines back and forth with out changing a thing!
Well in reality some adjustments to some lighting might be necessary or some tweaks on some shaders but nothing major.

No need to for a complete overhaul of every shader and especially no need to re-animated materials such as fire or floating water!
When ever we feel ready we could boost the visual quality by just the click of a button.

Also we did not just port the old assets and shaders to Eevee we also improved various aspects of those.
As soon as we’re ready we’ll release the entire shader library on Blendswap so other creators can use them as well.

Limitations we still face:

Actually those are no big issues but still limitation we still face.

Eevee does not allow for rendering on multiple GPUs nor does it allow to be rendered on CPU at all.
The usage of a render farm is therefore no option but also not necessary.

The two most limiting factors are that this entire Z-Ray Entertainment thing is essentially a one man show by me, Vortex Acherontic.
One guy for the models, textures, shaders, lighting, animations, sounds and post production. Production time still hits hard but a lot less.
The second limitation is, we do not gain any income by our animations and therefore time needs to be split between real life work and our projects.

The Future:

By moving to Eevee we’re now able to work again on our Minecraft animations again.
Hopefully finished or restart discontinued projects and most importantly create new ones, better ones and finally get Adventures of Steve done!