END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

You can calculate the normal (it's not really fake, you just estimate it) depending on the surrounding area. I use this in my own openCL renderer of which you have the code (in my own topic) I used http://blog.hvidtfeldts.net/index.php/2011/08/distance-estimated-3d-fractals-ii-lighting-and-coloring/ to do this, even though you could do it with a z-buffer as well.

I'd just recommend using the common shading algorithms like Lambertian and Blinn-phong. It gives nice results and it's pretty simple and fast. If you got everything working you could try using different shading algorithms as well, there are a couple interesting not frequently used algorithms out there which might be worth looking at (Cook-Torrance, Oren–Nayar, etc)

Personally I'm not familiar with photon mapping and path tracing, but from what I read on wikipedia is that you need the information of the entire 3d world (which you don't have when rendering fractals with a distance estimation algorithm) and it is very, very slow.

I did quite a bit of lightning last year, so I know how it works. You won't get such a smooth surface as on that picture, since single precision is too limited.

as it happens, the very first perspective 3d mandelbulb render had full global illumination, rendered with unbiased path tracing and metropolis sampling on top: http://www.fractalforums.com/3d-fractal-generation/true-3d-mandlebrot-type-fractal/15/

that was back in 2007, and yes, it was outrageously slow! i still want to re-do it with indigo renderer, using the gpu for doing the intersection computations; it's written up on our whiteboard here 

thank you very much !
that help me a lot... and confuse me

At first, i tought about a mandelbulb within and empty sphere and an omni directional light.
Hum... that's the worst possible case ! (as any ray will participate to the rendering, isn't it ?).

Now i think about a single infinite plane, a mandelbulb floating above it, and an uni directional light (a sky).
I think about starting with only greylevel, no color.

Now.
We know exactly where ie the camera and we know where is the light and can quickly find if, given a single point :
- there is a direct path to the camera
- there is a direct path to the light source

If there is no direct path between the point and the light source, the point will be black and its brightness will be (eventually) determined by bouncing ray.
If there is a direct path between the point and the light source (which can be easily determined by raymarching in the inverse direction of the unidirectional light. if it doesn't hit the mandelbulb after marching up to a radius of 2 from the center of the mandelbulb, then it goes up to the sky)) the brightness of this point will be at least the brightness given by the light source (according to the normal of this point).

Then, from this point, we bounce more or less randomly (well, in a hemisphere according to the normal) and do the same test again until maxBounce.

Do that make sense ?

The method I described is the same as used in games and other realtime stuff and it's very fast (and you can still make really nice images with it) If you want to go for speed (which is the primary reason people program for the gpu nowadays) that would the way to go. If you want perfect pictures the other methods described in this topic are better (personally I only had experience with the realtime shading algorithms) If you really want the perfect images you should stick on the cpu in my opinion because it just has a lot less limitations (single precision is a bitch) and it's a lot easier to debug. One of the reasons I'm writing in openCL is because I want more interaction than current programs, which you throw away if you implement complicated lightning and stuff. Just my opinion ofcourse, if you make the same decisions as me you'll probably end up with the same program 

Not mine. I know recent Nvidia cards have it, but there only a couple of Ati cards that have it.

Even if you're using single precision, writing code for a GPU just as you would for a CPU is a bad idea. The architecture is different, and heavy branching alone can effectively turn your 800mhz GPU into a weak 800mhz CPU with just a few threads. If you don't know why, then you don't understand GPU architecture, and I'd suggest taking a look at how they work before claiming 100x etc There's definitely massive potential with GPU for compute-limited workloads (fractals are pretty ideal since they use very little memory), but realising this potential in practice requires quite some care.

As a point of comparison, in Indigo Renderer the GPU can be used to accelerate such ray tracing queries, but sometimes it's not much faster than using just the CPU (which has huge caches and excellent branching "agility"). We went with a simple implementation first since it needed to work with both CUDA and OpenCL, however now we can go back and better adapt our algorithms to better exploit the new system.

Hmm I don't think the definitions you've given are correct, Syntopia.

In global illumination, the (surface) rendering equation describes light transport (in a vacuum). Roughly speaking it's L_out = L_emit + integral over all angles { R(L_in) cos(theta) }, and in this setting a diffuse BRDF R is just a constant k / pi, with k in [0, 1).

Luminance is a completely different quantity, which is perceptual in nature rather than a basic physical quantity.