A Question about Ambient Occlusion

[dcuny]

Max Tree Depth to 1

Ooops. Sorry about this, I should have tested it first. The value of Max Tree Depth should be 2, not 1. Otherwise, there won't be any bounces at all - the raytracer will stop at the first object it hits.

As for the speed, just about any method that attempts to simulate global illumination is going to be slow.

I don't see any particular reason why the Blender raytracer can't be extended to include path tracing. If it can support ambiant occlusion, other raytrace methods - including photon mapping - should work.

[Dani]

Hello!

dcuny, your explanations are quite interesting!

But is there a reason for blender's RT being slow? of course it depends on the type of scene... but only tracing transparent shadows takes sometimes forever. Is it a matter of optimization of the RT functions or is it that the current rendering system just can't support heavy RT duty?

If that's the problem, what would the current renderer need to support big RT and, further on, GI tasks?

BTW, these questions aren't only addressed to you, dcuny, but to anyone capable of answering.

Subsidiary question: does Blender's Renderer have a name? Browsing through the code I saw "vanilla"... is that it's little name? it'd sound sweet :]

Dani

[dcuny]

I think the answer isn't that the raytracer is slow - it's that the zbuffer algorithm is so blazingly fast.

The nice thing about a hybrid renderer like Blender (as opposed to a "pure" raytracer renderer like YafRay) is that you only have to use the renderer when you really need it. The zbuffer determines the "first hit" object, which is generally the most expensive raytracing operation. Raytraced shadows are relatively cheap, because you can stop searching as soon as you find an occluding object.

Reflection, refraction and other cool stuff is much more expensive by comparison, because you have to go through all the search space until you find the closest object. There are ways of reducing the cost of this (and Blender implements a number of them), but they are much more expensive relative to their zbuffer equivalents.

[Marty_D]

[edit]

[Dani]

Yeap, when you're used to the Z-buffer, RT seems like it takes forever, even if just takes a few seconds more to trace the shadows, indeed :]

I'm stil wondering how an app such as Cinema 4D (I tested the 5th version, before that new RT they incorporated) and already, there RT was blazingly quick on a PII 300mhz.... I mean... how did they do that? Refraction and reflexions obey to the same laws whatever the soft...

I'm just being curious, and it might be drifting OT.

Anyway, thanks for the answers!

Ciao!
Dani

[matt_e]

Moving this very informative discussion to the Rendering forum

[cessen]

The reason that Blender's ray tracing is currently so slow is largely because it's octree optimization is not particularly well implimented.

I haven't looked at the code, so I don't know this for sure, but I suspect that the algorithm it uses to build the octree is not adaptive, and thus it has to be limited to a certain level of subdivision for the sake of memory limits.

Ideally the method would use a zero-tree structure (I think that's what it's called), so that empty nodes of the octree structure don't have children. Also, ideally, it would continue subdividing areas of space until each node has only a certain number of polygons in it. Currently, it stops at a certain number of subdivision itterations regardless of the number of polygons in a given node.

[cessen]

I believe that Ton is already working on this (though I'm not sure), but AO can be sped-up significantly by using a method very similar to the one presented in "Ray Tracing With Adaptive Super Sampling in Object Space" (http://www.cs.uaf.edu/~genetti/Research ... 93/GI.html). I like to refer to it as "pyramid tracing", though I'm not sure if it has another name that is supposed to be used. Anyway, pyramid tracing is a way of taking advantage of space-subdivision optimizations by accounting for spatial-coherence among rays.

In short, if you have a bunch of rays originating from the same point (as you do with AO), you can treat them collectively as a pyramid. You can then trace that "pyramid" through the octree structure until it hits a node that has polygons in it. You then subdivide the "pyramid" in to smaller pyramids (i.e. regrouping the rays into multiple smaller groups), and start checking those. You continue doing this recursively (tracing pyramids until they hit an occupied node, and then splitting them into smaller pyramids, and tracing those until they...) until you eventually split the pyramids down into the individual rays.

This "pyramid tracing" optimization avoids a lot of redundant ray-tracing through empty space, and is a particularly effective speed-up when you are dealing with a large number of rays origination from the same point in space (as is the case with AO, area-lights, and blury reflections/refractions).

[dcuny]

You're right; in Ton's notest on the raytracer he mentiones that it's got a fixed maximum size of 64x64x64.

There are a number of optimizations that it performs, though. My favorite is caching the last hit element on a shadow ray; I filched that for my own raytracer.

But you can always find another way to speed up a raytracer - it's sort of the nature of the beast.

[cessen]

But you can always find another way to speed up a raytracer - it's sort of the nature of the beast.

Very, very true. And I'm sure that over time Blender's raytracer will be optimized more and more and get faster and faster. After all, optimization doesn't change functionality in this case, so it can be improved more and more without version-compatability conflicts.