Mitsuba – A physically based renderer | Hacker News Reader

Mitsuba – A physically based renderer

mitsuba-renderer.org

25 pointsleohutson8 comments

Mitsuba was referenced in the recent Siggraph paper by DICE (battlefield4) as the source of ground-truth for verifying their new volumetric rendering system.

http://www.frostbite.com/2015/08/physically-based-unified-vo...

(Starting at slide 31)

This is fascinating. If I'm reading it right, this is a "research" renderer, rather than a "production" one, since it uses the CPU, not the GPU, for computation?

AFAIK renderers used by the movie industry seldom use the GPU if at all... For plenty of reasons, the scene size not being the least...

RedShift, a GPU-based renderer, is starting to get quite popular though in short form high end work like commercials. Haven't heard of it being used on movies yet, but I think it is coming.

A lot of production renderers use the CPU as well - most Dreamworks Animation and Pixar films are still mostly CPU-based rendered. I've used Mitsuba and it is pretty slow and incomplete compared to production renderers (Mitsuba's scene definition format is just brutal compared to Arnold or V-Ray or PRMan), but some of its results are not yet available in production renderers.

It's a bit unfair to compare the speed of Mitsuba with the speed of Renderman. Mitsuba only has a simple KD-Tree (although highly optimized), while RenderMan most likely has a state of the art BVH, which utilizes SIMD instructions. RenderMan also has a lot of sampling controls, while Mitsuba's path tracer has always traces one light and one BSDF sample on each intersection. There are multiple software engineers at Pixar that solely focus on optimizing RenderMan, while most of Mitsuba is implemented by a single person, who is a full-time researcher.

Mitsuba lacks a lot of features that are necessary for production: there is no proper support for hair (Mitsuba only has a simple Kajiya-Kay shader and no specialized acceleration structure for ray intersections), there is no support of subdivision surfaces, no support for displacement mapping, etc. All of these features are necessary in production.

Mitsuba is great for research though. It has support for a lot of experimental rendering algorithms (such as Metropolis Light Transport), which are not supported in production renderers. Due to Mitsuba's modular structure it's also incredibly easy to implement new algorithms, which makes Mitsuba a great framework for comparing rendering algorithms. A lot of papers use Mitsuba to compare their new algorithm to other algorithms.

Most production renderers use CPUs (just like Mitsuba). GPUs are incredibly powerful and some benchmarks show 400% speed improvements over CPU-based renderers. The problem is though is that GPU-based renderers struggle with the scenes that are used in production. Typical production scenes contain over 250GB of textures and over 10s of GBs of geometry (pre-tessellation). This isn't going to fit the in the memory of a GPU and the GPU will spend most of the time loading assets from the hard drive (or network).

how does this compare to maxwell render?

Reply on news.ycombinator.com