(L) [2006/09/05] [Phantom] [Soft shadows] Wayback!This morning I found a nice idea in my head.
It goes like this:
- Soft shadows are expensive. I mean, diffuse reflections are bad already, but soft shadows would have to be evaluated for every intersection point, possibly for multiple light sources. That's never going to be runtime.
- Typical traversal & intersection results in ~2-3 intersections.
- MLRTA traces a frustum though the kd-tree.
Wouldn't it be a nice idea to build a 'beamtree' while traversing the kd-tree? For those unfamiliar with beamtrees: It's basically a 2D BSP of the frustum. So, we start with four splits to bound the frustum itself; next for each triangle (remember, just 2 or 3) this tree is updated using the edges of the triangles that we would normally intersect with individual rays. At the end of the process, we can simply determine the area of the 'solid' areas in the BSP, and this gives us an analytically correct number for the occlusion at the intersection point. No noise, no approximation. And it seems cheap enough too.
Only problem I see at this point is that MLRTA is not very good for shadow rays, because it doesn't really keep track of distances along rays. That same problem hurts this idea.
EDIT: Suppose the 4x4 packet found 16 intersections. Now we could also build a volume between the intersections and the area light. Next, we could make a list of the primitives that intersect this volume. For each of the 16 shadow volumes, we now only need to add primitives from the list. This might not be very nice if the intersections are not closely packed together.
_________________
--------------------------------------------------------------
Whatever
(L) [2006/09/05] [MishoM] [Soft shadows] Wayback!I've been thinking about something like this too, but haven't had the time to try it (besides my raytracer doesn't exist yet). I was thinking of tracing a rectangular beam (represented by its four corner rays) and spliting it in two equal beams which are then processed in the same way. A beam is split if it contains (whole) triangles or if at least one of the rays intersects a triangle, but not all oif them intersect the same triangle. If a beam gets smaller than a preset limit, the number of intersected corner rays determines if for this beam the light is considerred 100% occluded, 75% occluded, 50% occluded, 25% occluded or not occluded at all.
(L) [2006/09/05] [Michael77] [Soft shadows] Wayback!How about having a separate Shadowtree if you have memory to spare? For spotlights for examples, you only put those triangles in the tree which intersect the spotlight cone, the rest is discarded (since it is not lit anyway). Usually only a fraction of the scene will be lit by a spotlight, so traversal of these trees will be a lot faster than traversing the whole tree. For rectangular Area lights, this will be the same, although computation of what is lit or not will be a bit more complicated. In a further step you could also consider the intensity falloff of a light source.
I think, mental ray offers this although I haven´t checked how much can be gained from this. Of course, a BIH will probably make better use of this than a kdtree, since bih traversal is generally a bit slower and memory consumption is far less.