> A single frame can take more than 24h to render
What, really? I was under the impression that pixar had a render farm large enough to render frames in minutes or even seconds.
What, really? I was under the impression that pixar had a render farm large enough to render frames in minutes or even seconds.
Higher resolution, and stereo (3D), are also to blame. Toy Story was rendered at less that 1080 HD resolution!
[1] https://www.quora.com/How-much-faster-would-it-be-to-render-...
With MC path tracing, the noise you get is pretty difficult to resolve, and a lot of companies are using denoisers afterwards to clean up the renders, as it's just not cost-effective to keep them rendering to that extent as denoising is faster.
I'm in the industry, and [citation needed]. Four hours is not remotely typical for a final render frame, especially now that path tracers are the de facto standard.
> Renderman, what we use at Pixar, is also fast but for the quality we strive to achieve is very high, so we we squeeze as much as we can into it until it just becomes too slow.
So if the renderer became faster, we would just add more quality, and make it "slow" again.
Okay, but reality only has so much quality. There has to be a limit somewhere.
Regarding model complexity - that doesn't really matter these days - if you want to raytrace a scene, unless you want to do full-on deferred raybatching and geo paging (like Disney's Hyperion does), you need to fit the scene into memory, so other than at startup/ingestion time, model complexity doesn't really matter in terms of IO. Also, Pixar's base level subd meshes are really rough (compared to what you see in VFX in general - for VFX base levels are probably subdivided down 2/3 times more), so the geo given in in Pixar's case isn't actually that bad.
I guess that you don't want to page in full models (as you either need a very large amount of memory per thread, which means smaller ray batches, or you need to have a shared cache, which means waiting on other threads). So you'll probably need something similar to Toro (as described by Pharr et al.), which just doesn't seem very efficient to me (as grids have improved little compared to BVHs).
Easiest way is to have a two-level BVH, where the lower level just has overall AABBs of every object in the scene which contains a "geometryInstance", each of which then contain another object-space BVH of the triangles (or other primitives).
This is trivial to do, but you take a pretty big penalty for not being able to look down to the primitive (microtriangle, microcurve) level for the lower level BVH, so the quality of it isn't as good. So for stuff with hair on skin, you've pretty much got two objects overlapping which sucks for traversal performance. There is a way around this, but it involves storing a pointer to each primitive in the BVH which is expensive and mixed transforms / motion blur get complicated with this.
The more complex way of doing it would just be to use the single level BVH and partially build it - given the lengths Disney are going to in order to sort and batch the rays, it sounds like they can constrain stuff such as all rays they send in a batch are going in a similar direction anyway, so you can cull a lot of stuff.
These days in VFX we're pretty much just fitting stuff into memory anyway - there's no other option. PRMan does support geometry paging in theory, although Arnold doesn't and VRay only partially does (with VRay meshes), but performance absolutely sucks doing it, so buying more RAM is just the easiest/cheapest solution all round.
Disney are only really doing deferring / reordering to such an extent because of their love of PTex which sucks with random access IO, so...
They do mention some tests with "out-of-core rendering of scenes with massive amounts of geometry" in the paper, but there isn't much info on it. AFAIK their patents mention streaming in geometry too.
I know that buying more RAM is probably easier, but it would be interesting to render very large scenes on commodity hardware. I guess paging in geometry is just too much of a hassle, you constantly have to stream in geometry to memory; to compute surface derivates, to do subsurface scattering, to sample arbitrary geometry lights, etc.
But unless you batch and re-order rays (and I'm not convinced doing this is worth it if you're doing more than 3/4 bounces, as the incoherence just makes things a nightmare), there's no point really doing this (unless you're happy with very slow performance - even mmapping stuff is slow).
Ray re-ordering is indeed a nightmare, but sorting very large ray batches (millions of rays) into coherent ray streams is less of a hassle, and it should enable coherent geometry access (which amortizes the cost of those reads, not sure to what extent).
For stuff like hair where you need loads of scattering events or for SSS doing that (paging subsections of shapes) is just going to thrash any geometry cache you have unless they're quite big.
And I'm still not convinced by ray sorting: it means your light integration is extremely segmented into artificial progressions as you expand down the ray tree, and makes anything regarding manifold exploration (MLT or MNEE) close to impossible to do well.