Octane Render review

Introduction

When it comes to renderers, 3DS Max users have never had so much choice. The list is already long: Mental Ray, V-Ray, Maxwell, IRay, Indigo, FinalRender, Arion, Thea, Corona, FurryBall GPU on the horizon, etc. And now Octane Render is fresh out of commercial beta promising ease of use, interactivity, integration into a wide range of applications and the claim of being “the first GPU based, un-biased, physically accurate renderer on the market”.

Octane started life as a product of Refractive Software, founded by Terrence Vergauwen, a key developer of LuxRender. In March 2012 Refractive Software was bought by Otoy, developers of LightStage and Octane’s sister product Brigade, a real time GPU-based cloud game engine. Otoy also has investment from Autodesk.

The renderer comes in many flavours: as a standalone application for OSX, Windows and Linux; an expanding roster of plugins that bring native Octane rendering to 3DS Max, Maya, Lightwave, Cinema 4D, Autocad, Softimage, etc.; and a competitively priced cloud-based edition to be released later this year. This review will be focusing on the 3DS Max plugin, though many of the same features are present no matter the platform.

Biased vs. Unbiased

Octane used for architectural visualization –
image by Andrian Radkov

The advantage of using a physically accurate render is the ease with which photoreal images can be created without needing to learn the hundreds of esoteric parameters needed to master a biased renderer. The downside is usually a significant increase in render times needed to clear the noise that comes with using unbiased algorithms. GPU based renderers’ great promise it to overcome this hurdle using the massive parallel processing power of modern video cards.

What this means in real terms is that Octane can produce some stunning images rather quickly. The developers claim speed gains of 10x–50x Compared to CPU based unbiased renderers – dependent of course on hardware – with 10x–15x speed increases to be expected. It’s not all about speed though, if you’re coming from a biased renderer you’ll probably find it much easier to use. It can take years to become proficient with V-Ray, but decent results can be achieved with Octane almost immediately. Finally, it’s interactive, being able to use the OctaneRender viewport to place lights, edit materials and frame a composition in real-time is a game changer.

Hardware Requirements

Octane uses a custom CUDA implementation and therefore requires an NVidia card to run. OpenCL is not compatible, though according to the Octane FAQ there are plans to support it when the technology matures. Octane will however work relatively well even on older cards, 8000 and up and a minimum of 96 CUDA cores are cited, as well as high end Quadros and Teslas. Moreover, adding cards to a system results in a linear performance increase, meaning two identical cards will give twice the performance of one. Cards models can be comfortably mixed in the same system too, and there’s no need to use SLI. Multiple cards can be managed from the CUDA Devices tab where each card can be easily activated or deactivated with a simple tickbox.

Octane Render was reviewed on a single, fairly modest, mid range 560ti card with 2gb of VRAM. In early tests it was obvious that Octane was pushing the machine to its limits, the screen became intermittently unresponsive – the promise of real time interaction seemed unlikely. To counter this, Otoy recommend a dual card setup with one running the monitors and at least one more card dedicated to rendering. Fortunately, thanks to a tip from Tom Glimps, it was possible to use the motherboard’s built in Lucid Virtu technology to use the IGPU to run the system, leaving the 560ti to deal with rendering. This was as simple as making sure the drivers were up to date and turning on a couple of settings in the BIOS. It’s a great compromise if your hardware supports it, and Octane ran exceptionally well using this setup. Since starting this review Octane introduced a Low Priority option to help maintain screen responsiveness and usable interactivity. The short video below demonstrates the cover scene using the Virtu setup.

Hardware is currently a GPU renderer’s biggest limitation. The size of scenes is restricted by the amount of VRam you have on- board and though it is possible to improve speed performance by adding additional cards, the same is not true for memory, since each card needs to have the full scene loaded. This also means if you’re mixing cards, your usable memory is limited by the card with the lowest specification.

There’s also a limit on the number of texures that can be used, imposed by the CUDA API. This is dependent upon the card architecture you’re using. For pre-Kepler cards the limits are 64 RGBA textures, 32 greyscale textures, 4 HDR RGBA textures and 4 HDR greyscale textures. For Kepler architecture the allowances are more generous with 144 RGBA textures, 68 greyscale textures, 10 HDR RGBA textures, and 10 HDR greyscale textures permitted. Kepler GPUs also introduced the concept of bindless textures which theoretically removes these limits, though this has yet to be integrated into Octane because it would remove support for pre-Kepler cards.