|
|
It would be nice if you could provide us with some more detailed information about the scene rendered, in particular lightmap dimensions, patch subdivision level and total number of polygons before octree and bsp processing.
There are only 42 polygons in the scene. The lightmaps are 128x128 and contain combined polygons. I believe the floor uses a lightmap area of 38x38 lightmap texels. Because the visibility result is exact, the lighting is rendered into the lightmaps with precise anti-aliasing precision, so there's no need to sample with multiple rays.
The original was rendered with 112 patches and 166 elements. The new one was rendered with 8856 patches and 8856 elements (that's a 1:1 corellation of patches to elements.)
Now.. that's not entirely true.. only mostly true -- this is where the adaptive patch technique comes in.
Because it is using a progressive-refinement-like approach (each iteration, the patch with the most energy is shot), the first few iterations are very important for quality. If, for example, I had used a patch subdivision of 4x4 (which would be a 4x4 grid of elements per patch), then the patches would be fewer, but the shadows might not look as smooth as they do (remember, the scene is discreetized.) Of course, it is much slower to use a 1:1 corellation. So, the user enters a threshold for energy emission, and when the energy drops below the threshold, each group of 2x2 patches are combined into a single patch (at which point, a patch would be a group of 2x2 elements.) Combining patches like this means the amount of energy effectively quadruples for each sucessive iteration. So the process speeds up. Once the amount of energy being shot for an iteration drops below the threshold (again) then a group 2x2 patches are combined again (now each patch represents a 4x4 grid of elements.) This continues until all energy is shot, or until the size of a patch reaches (another) user-specified limit.
This may sound severe, and it can be, if used improperly. I tend to use a threshold of 0.01% (i.e. when the amount of energy being shot for a single iteration is less than 1/10,000th of the total scene energy.) And I limit the maximum patch size to 8x8 (64 patches.) But by the time it reaches 8x8, the amount of energy is so negligible, it is only contributing a negligible amount of energy to the scene.
If I had to guess, I would say that roughly 90% of the energy in the scene was rendered with a 1:1 (patches:elements) ratio. It probably then stepped up to a 2x2 patch size until about 94%.
I have a question for you though. Basically, I want to know the difference between radiosity and raycasting. ... Have you ever used raycasting to produce lightmaps?
Yes, I've used ray casting. The results don't compare to true radiosity. :) And if the radiosity solution is accurate, then the results are that much better.
What is radiosity? Pretty simple... think of a ray tracer: you ray trace from the eye to a surface, maybe reflect the ray, and check for shadows. You then plot the pixel color to the screen. This is far from the way things happen in real life (radiosity, too, is pretty far from reality, but it's a lot closer!) In the real world, radiative flux (i.e. energy, light) leaves a light source (which has area, rather than an infinitely small point) and lands on walls. Some of that energy is absorbed (based on the reflectivity of the surface) and the rest is bounced back into the scene. Some of this energy enters your eye, and you see the surface. Some of this energy hits other walls, where some more energy is absorbed and the rest is bounced back into the scene. You keep bouncing light until you reach "convergence" (all energy is absorbed.)
In response to Jare's questions, immediately above this post
Heya, buddy! :)
Yes, the red/green light (on the smaller boxes) does come from the light reflected from the walls. It's called "Color bleeding". You say you prefer mine... in reality, the left-hand image is much closer to the physical cornell box that was used in the original tests (where the rendered image was compared with the real thing.) I don't think mine is any less accurate -- I just used different surface colors and reflectivity values because I don't know the actual values. Had I known the actual values, I believe they would be so similar, you couldn't tell them apart.
The reason you don't see as much color bleeding on the front wall, floor or ceiling is because the amount of energy being reflected from the colored walls is minimal compared to the amount of "white" energy landing on those surfaces. You see more red/green on the sides of the smaller boxes because they get less of the white light. And if you think about it, the sides of the smaller boxes ARE darker, because the amount of energy (red+green+blue) is less than that of the white surfaces.
The edges where the boxes meet the floor is caused by lack of subdivision (in the left-hand image) and lack of lightmap resolution (in the right-hand image.) In order to eliminate these, one would need to cut a hole in the floor where the boxes sit to prevent the lightmap pixels from filtering under them.
So (1) no, none of this is accuracy-related, unless you consider the lightmap a source of accuracy loss, and (2) no, I never said mine is better. :) My goal was never to improve upon the cornell box solution, but rather to reach it.
|
