Skip navigation.

Rendering

Table of contents

Rendering

As I mentioned in the introduction, the project was started in mid 2005, and back then, I was using C4D R9 and I was thinking of rendering the image with AR. But, because I didn't work on it then, I changed my mind. So, in mid 2007 when I resumed the project, I was using C4D R10 and I thought of giving Vray a try. I worked on the project a lot of my time and I managed to get it almost done. But, I was using C4D R10 32 bits version and Vray 1.0. This prevented me from completing the project because I reached the memory limit of 32 bits and I was encountering random crashes during long renders. In the end, the project was finalised in C4D R11 and Vray 1.1, on 64 bits. This slowed down the whole project. In early spring of 2009, I could have rendered the finals, but only in August I managed to do so.

Optimisations

The scene, as you can already tell, is very complex and it did become a hurdle to manage. For the objects I modelled, I did my best to take into consideration the final output resolution and the perspectives from which it should be rendered. As such, the polygon count is moderate. Although, I didn't make any compromises in terms of polygon count. The highest amount of polygons is concentrated on the macramé (1,8 millions polygons) and on the flowers (840 873 polygons). In total, the scene has 4,24 millions of polygons and 2560 (9845) of objects. During render time, the render takes about 4 to 6 Gb of memory. Another fact is that I got 223 different materials in C4D and 136 files which are image textures totalling 1,85 Gb. The following wireframes are more illustrative in terms of polygons density:

Wireframe: Piano room POV 1 Wireframe: Piano room POV 2 Wireframe: Piano room POV 3

The big culprit of the scene was, in the early stage, the memory usage and, in the final stages, the render times. To optimise the memory usage, I converted all the grayscale images which were stored as PNG or PSD, in RGB mode to grayscale texture files in the TIFF format. This solution was very good for me at that time, because I was using C4D in 32 bits. It saved me about 300mb of memory usage.

Because of the way I did the shaders, very complex, and perhaps, exaggeratedly detailed, the render times, as the scene evolved, slowly increased without me noticing it is happening. At the end, when I had finished most of the scene, it was rather too late to rework all shaders.

Initially, all my shaders were not baked. I've been informed that baking shaders helps a lot. So, I baked the bump maps of the most important objects: the room walls, including ceiling, the carpet and the armchair covers. I also baked the SPDs for the carpet and for the wall painting frame. Baking of shaders helped a lot, because during render, the CPU was better utilised, 100%, both cores, and in synthetic renders (e.g. just the walls and the floor) the render times dropped by approximately 50%, but I never actually did complete render tests for comparisons. As I noticed, the render times were reduced by 10-25%. Here's the table of render times I did when I baked the bump maps, on Saturday, 14 March 2009:

Render time comparisons for bump maps. Resolution: approximately 510 x 350 px. Empty room, only walls visible.

Keep in mind that even if the results seem very good, they are not representative for the overall impact on the render times when all objects are visible. As such, I consider these as being synthetic tests and also that they are not accurate.

Another thing which helped was to increase the dynamic memory limit in the render settings of Vray. I have 8 Gb of physical memory and until then, C4D was crashing unexpectedly during render times. This little aspect, prevented me from doing the final renders in early spring of 2009. Since I changed the setting from 400mb to 4000mb, I don't encounter anymore crashes during renders.

I've studied quite a lot what slows down heavily my renders and I concluded that it is the reflections and the bump maps. The shaders I have in those channels are too complex, thus they require too much sampling and almost all my materials use at least one specularity channel for dim reflections. The following comparison table of render times illustrates this:

Render time comparisons with different rendering features. Done in 1st of August 2009. Resolution: 476 x 384px, armchairs - POV 2. Render settings: GI - very low quality preset, AA DMC 1/2:

Despite the fact that SPD and Glossy effects have a minor impact on the overall render time, it needs to be mentioned that these features have a greater impact on the render times as the resolution increases, or as the AA and GI quality settings are increased.

I tried to optimise the render time by using a light portal for the big windows. But, this is not a solution, the rendering time is a bit slower and the image gets noisy. I could clear the noise, but at a great expense in terms of render time. I thought I'd complicate things even more with it, so I dropped this idea. Here's a test render comparison and the render times:

Physical sky and Light portal render comparison

Only one issue wasn't solved in the end: the enormous render times. Even when I baked a few of the most important shaders, I didn't manage to cut down the render times by 50% or more. On my PC, Core 2 Duo E6700, I calculated that one final render would take several months. The final images were rendered on a Xeon 5420 dual quad-core, 2,5Ghz with 12mb cache and 12Gb of RAM, thanks a lot to Giel-Jan Wijns (renderplatform.net) for doing the renders. Each render took 6 days to finish.

I cached 1,27 Gb of GI solutions for the finals renders (538 mb), ambient occlusion passes (197 mb), clay renders (255 mb) and sunlight passes (315 mb). Most of the renders were done with SPD enabled to make sure the results will be up to my level of requirements.

Final render settings

GI set to very high quality preset:

Anti-aliasing:

DMC sampler:

Colour mapping settings: Reinhard mode, multiplier 2.25 - 2.7, burn 0.2, gamma 2.2

Previous page: Light setup

Next page: Post-processing

Send me a comment

Any comments are welcome! No field is required, except the message itself. If you want me to reply, include your email address.