darkpore

Same here...

Pixar and Disney are different studios...

The global illumination tech used on monsters university was just standard path tracing with physically-plausible sharers - the first time pixar had used that instead of radiosity caching. Other studios have been using path tracing for years before - pixars lighters are very good however, so the results are very good.

Yep - you evidently didn't read mine as 165 k lines of c++ isn't exactly a small benchmark :)

Anecdotal, but I've seen similar improvements over g++ in my code.

Does it?

http://imagine-rt.blogspot.co.uk/2014/12/c-compiler-benchmar...

Would GeometryInstances go directly into an acceleration structure? Surely objects which point to the geometryinstance and each have a worldspace transform are what go in the scene level acceleration structure...

Generally it's advisable to templatize acceleration structures so they can natively cope with triangles, objects and possibly other primitives (spheres and curves) separately.

Rather ironically, Arnold's standard shader still has bugs meaning its Cook-Torrance microfacet model isn't completely energy conserving at glancing angles...

Not the same version then? :)

I guess that depends on your definition of 'easily' - you can provide custom allocator s fairly easily. What's more problematic are things like the memory usage patterns of std::vector and std::string. Once you know how they work you can avoid the pitfalls or use custom alternatives.

Games and other high performance users generally used to stay away from the STL. Sony had their own version of STL which addressed some of these issues.

You can get around a lot of these issues by reserving the size needed up front, or using a custom allocator with std::vector. Not as easy, but still doable.

The reallocation issue isn't fixable this way however...

Is there any plan to abstract away the need to handle drawing the widgets yourself, and provide layout functionality?

lol - you're aware that most web browsers are written in C++?