Bringing Cafu beyond the current generation.
Posted: 2012-01-18, 21:44
I'm from the world of Maya and Blender, where graphics come slow with astounding results.
When thinking of how to get these results with conventional raster it dawned upon me... photon mapping compared to the actual ray tracing consumes soo little CPU power that even with many thousands of rays, it can be done in realtime, even without GPU acceleration.
In this demo 1000 light rays are being cast and bounce in realtime, rather inefficiently, then blended to look like there's more. Click the third icon to see photon mapping only, imagine merging raster with photon instead ray with photon, you'd get the same results but at 300 frames per second with software photon, 3000 fps with gpu accelerated photon.
http://www.cc.gatech.edu/~phlosoft/photon/
The idea, no more CaLight(as it currently is), no more lightmaps, no more long compile times waiting for things to render, realtime lighting with results superior to CaLight and any other game engine, even comparable to "low-quality" raytracing.
CaLight could be redubbed CaRay because it's new role will be a form of Photon Mapping.
Graphics will be a harmonization of raster and ray, unlike everyone else out there who strictly resides on their own side of the fence.
Every light has 6 variables:
R, G, B - Integers for colour and brightness.
Rays - Number of rays light casts, likely have a dropdown list of standard quantities.
Range - Cafu units, overrides RGB intensity to keep light from casting very far, eating a lot of power.
Bounce - Number of times rays can bounce, 0-4, default 1.
There would be 3 types of light:
Panel - Parallel ray casting sheet, has an extra diffuse value so rays come from a more randomized factor, can be used for sunlight.
Point - Standard omnidirectional light.
Cone - Spotlight, has angle values.
Efficiency:
- A light which is not in motion does not consume any processing power.
- A light can change it's colour and intensity with minimal performance hit since rays don't need to be recast, the point values only need to be changed.
- When an object is in motion being lit by rays, it's bounding box can be used to predict which rays need to be recalculated, dramatically increasing efficiency.
- Even if every light is in motion and the rays have to be recalculated every frame, the amount of computing power available in even low-end systems is great enough to have thousands of rays active.
- The slow movement of the sun allows it's ray calculations can be done at a lower priority.
- LoD is easily implemented with Rays, the further away you are, the fewer a light source has.
- Full HDR is more practical, HDR lightmaps have a massive footprint.
EDIT:
Methodology idea - Theoretically photon mapping could be purely for bounce lighting, saving the computational power of the initial rays and directing focus towards on global illumination, however then you'd loose the ability to have smooth shadows.
Efficiency ideas;
- To save power photon mapping could be configured to ignore flagged models, things which would be moving a lot or constantly or of high detail, those things would still be rendered in steps 1 and 3, but ignored by the photon casting(2) and illuminated by simply sampling local photons.
- To save power the photon mapping could be run on simpler meshes, by using the second highest LoD mesh, although the photon points would have to know where to parent to the more detailed meshes for a quality render(blending of 1&2).
When thinking of how to get these results with conventional raster it dawned upon me... photon mapping compared to the actual ray tracing consumes soo little CPU power that even with many thousands of rays, it can be done in realtime, even without GPU acceleration.
In this demo 1000 light rays are being cast and bounce in realtime, rather inefficiently, then blended to look like there's more. Click the third icon to see photon mapping only, imagine merging raster with photon instead ray with photon, you'd get the same results but at 300 frames per second with software photon, 3000 fps with gpu accelerated photon.
http://www.cc.gatech.edu/~phlosoft/photon/
The idea, no more CaLight(as it currently is), no more lightmaps, no more long compile times waiting for things to render, realtime lighting with results superior to CaLight and any other game engine, even comparable to "low-quality" raytracing.
CaLight could be redubbed CaRay because it's new role will be a form of Photon Mapping.
Graphics will be a harmonization of raster and ray, unlike everyone else out there who strictly resides on their own side of the fence.
Every light has 6 variables:
R, G, B - Integers for colour and brightness.
Rays - Number of rays light casts, likely have a dropdown list of standard quantities.
Range - Cafu units, overrides RGB intensity to keep light from casting very far, eating a lot of power.
Bounce - Number of times rays can bounce, 0-4, default 1.
There would be 3 types of light:
Panel - Parallel ray casting sheet, has an extra diffuse value so rays come from a more randomized factor, can be used for sunlight.
Point - Standard omnidirectional light.
Cone - Spotlight, has angle values.
Efficiency:
- A light which is not in motion does not consume any processing power.
- A light can change it's colour and intensity with minimal performance hit since rays don't need to be recast, the point values only need to be changed.
- When an object is in motion being lit by rays, it's bounding box can be used to predict which rays need to be recalculated, dramatically increasing efficiency.
- Even if every light is in motion and the rays have to be recalculated every frame, the amount of computing power available in even low-end systems is great enough to have thousands of rays active.
- The slow movement of the sun allows it's ray calculations can be done at a lower priority.
- LoD is easily implemented with Rays, the further away you are, the fewer a light source has.
- Full HDR is more practical, HDR lightmaps have a massive footprint.
EDIT:
Methodology idea - Theoretically photon mapping could be purely for bounce lighting, saving the computational power of the initial rays and directing focus towards on global illumination, however then you'd loose the ability to have smooth shadows.
Efficiency ideas;
- To save power photon mapping could be configured to ignore flagged models, things which would be moving a lot or constantly or of high detail, those things would still be rendered in steps 1 and 3, but ignored by the photon casting(2) and illuminated by simply sampling local photons.
- To save power the photon mapping could be run on simpler meshes, by using the second highest LoD mesh, although the photon points would have to know where to parent to the more detailed meshes for a quality render(blending of 1&2).