ATI's "Toy Shop" Demo is jaw-dropping

[KimB]

You could distribute the computing for Pixar-like rendering onto many PC GPU's just like they currently do among many CPU's.

But the primary problem is tha Pixar rendering depends upon sub-pixel triangles. Current GPU's just aren't optimized for this case, and as such would be rather slow at it.

 

[OICAspork]

You could distribute the computing for Pixar-like rendering onto many PC GPU's just like they currently do among many CPU's.

But the primary problem is tha Pixar rendering depends upon sub-pixel triangles. Current GPU's just aren't optimized for this case, and as such would be rather slow at it.

Thanks for the response. I appreciate it. Is the sub-pixel triangles the standard rendering mode in renderman, or something Pixar does for higher quality in their feature films? I'm asking if, at least in the short term, this would have greater effectiveness on lower quality 3D animation television shows where such high quality wouldn't be necissary or worth the added expense.

 

[Mark]

You could distribute the computing for Pixar-like rendering onto many PC GPU's just like they currently do among many CPU's.

But the primary problem is tha Pixar rendering depends upon sub-pixel triangles. Current GPU's just aren't optimized for this case, and as such would be rather slow at it.

I wonder if there would be a market for GPUs that are highly optimized for that kind of rendering?

 

[3dcgi]

I'm sorry I'm not making myself clear. What I'm trying to say is. Given the flexibility of current GPU hardware, would it be possible to map existing professional 3D-animation software to the GPU rather than the CPU such that the rendering is accelerated by the GPU (at least for any command that could be accelerated through the GPU pipeline) rather than sent to the CPU in order to massively increase the rendering speed. It doesn't need to be realtime, only faster than what could be done by a CPU (or CPUs) and have a speed gain adequate to make the software creation worth the investment. I hope that is clearer.

Erm... in case it isn't... one more example...

Pixar creates a scene in Renderman and similtaniously tries to render the scene on two seperate machines.

One machine uses a version of Renderman compiled to be rendered on CPU(s)

The other uses a version of Renderman compiled to render on GPU(s) with assistance of the CPU for any effects that cannot be rendered by the GPU.

Wouldn't the second finish first? I realize that Pixar uses massive, massive renderfams with thousands of CPUs, and currently it would be impossible or at least impracticle to do a similar array of GPUs (what is the current theoretical max for ATI GPUs?), but say a station wanted to create a new CG television series and didn't have the budget for pixar-sized renderfarms... couldn't software designed as I suggested drop the cost of producing such a show drastically?

I hope I'm finally clear.

You've obviously never heard of Nvidia's Gelato. It's a Reyes renderer that uses the GPU to accellerate portions of the rendering process, non-realtime.
http://film.nvidia.com/page/gelato.html

 

[Mintmaster]

Actually, it's not so bad. I implemented this method in the parallax mapping sample (both OpenGL and D3D) that's in the latest SDK. The storage space isn't bad at all. For instance for a 512x512 bumpmap, I converted that to 128x128x16 in L8 format, which is just 256KB, thus smaller than the bumpmap itself. The quality is excellent. I used dynamic branching in this demo, taking as many loops as required to get an acceptable error (max 128 loops). The max error can be adjusted in real-time with a slider so you can compare quality vs performance. I tried this sample on 7800GTX recently, and found that the R520 outperforms it with more than 2x.

I haven't implemented POM myself though (I should probably do that) so I don't know which method is better, though POM has the advantage of solving the self-shadowing problem too, which on the other hand can also efficiently be implemented with horizon mapping for other techniques.

The other advantage of POM is how it works with dynamic displacement maps like water, realtime surface damage, thick oozing goo dripping down the wall, etc.

I would definately like to see how much speed gain is obtained using the distance function method over POM. My guess is POM takes quite a few cycles on average.

 

[Andrew Lauritzen]

The storage space isn't bad at all. For instance for a 512x512 bumpmap, I converted that to 128x128x16 in L8 format, which is just 256KB, thus smaller than the bumpmap itself. The quality is excellent.

That's a good idea. I do know that you certainly don't need many surface slices to get a good result.

I used dynamic branching in this demo, taking as many loops as required to get an acceptable error (max 128 loops). The max error can be adjusted in real-time with a slider so you can compare quality vs performance. I tried this sample on 7800GTX recently, and found that the R520 outperforms it with more than 2x.

That's awesome news... as I mentioned I've been really impressed with the design of the control flow in the R520, although it was bound to come eventually (NVIDIA's implementation was almost more of a "proof of concept"). Man I need to upgrade my 9800...

In any case, both of these methods seem to produce good results and have good performance. I suspect in the average case POM would come out slower, but the R520's fast control flow does change the design of algorithms.

I didn't see in the demo, but it would be cool if they could easily combine POM with shadowing, etc. to get correct (displaced) shadows, both casting and receiving. With distance functions, it would be pretty trivial in a deferred lighting-based rendering system and would take almost no performance hit. I would imagine that the same would be true for POM... I wonder if they implemented that in the demo? There were no places that it was obvious to me either way, although I haven't gone through it in detail.

 

[NocturnDragon]

I would imagine that the same would be true for POM... I wonder if they implemented that in the demo? There were no places that it was obvious to me either way, although I haven't gone through it in detail.

Look at the toy shop sign, it has POM with shadows!

 

[Andrew Lauritzen]

Look at the toy shop sign, it has POM with shadows!

Does it also cast displaced shadows (onto other geometry, not just self-shadowing)? Receiving shadows correctly is fairly straightforward, but casting them would require some computate while computing the shadow map at the very least.