http://lists.blender.org/pipermail/bf-blender-cvs/2008-May/013885.html
The initial code has been commited to his branch, we should start seeing it really take shape pretty soon. Looks like another GSoC project is off on a good pace.
Can someone explain what is a lightcut. It isnt in my dictionary.
Thanks
It isn’t in ours either. 
Basically, it is a way to quickly render lots and lots of lights (thousands). This means that you could fake global illumination, image based lighting, and radiosity by approximating it them with tons of lights.
Here is some more information:
http://wiki.blender.org/index.php/User:UncleZeiv/SummerOfCode2008
Oh. Thanks. This looks like interesting idea. Still I think that proper Global Illumination would more interesting idea - I hope it will be at least faster than GI could be :).
hundreds of lights sounds like a nightmare
but the results are quite good based on the
images I saw.
The temple animation is stunning. I would
like to know the render time for that one.
What is that instant radiosity? How would it
work with lightcuts?
I am curious about how you manage the
lights or if this is just an internal system
during render time.
Would it work with texture baking and preview
rendering?
The thousands of light wouldn’t be set individually by the user, the user would toggle just GI, and under the hood Blender would calculate it as if it was thousands of point lights (and would thus be approximate). Same thing goes for instant radiosity.
The cool thing is that not only would you be able to make GI images in say 20 minutes, but you could also make really low quality test images in a few seconds.
and it looks that it could be also very usable for animation
similar to the difference between AO and AAO.
In the devs blog he posted a screen shot where he showed
the amount of lamps used - looked quite clustered.
For my class project I used GI for the first scene (In C4D not Blender.) and render times were not as low as I’d like, so I will be looking forward to this.
As he said on his blog,
Of course, in an actual implementation, end users wouldn’t be able to see all these individual lights in 3d view… fortunately!
this is quite interesting that this is actually fast because it uses so much lamps.
I am curious how this works with color bleeding and also if this might make caustics possible.
Have you seen the examples? It is visually indistinguishable from GI.
@Cekhunen:
About color bleeding: yes and no. As I understood it, light cuts is what mp3 is for wav. It will strategically place fast type lights (sun lamps, spotlights, point lights) that visually will yield the same result as the original setup. It is used to substitute all kind of lights. It is most interesting when using expensive solutions. So yes, you can extent it to simulate radiosity where color bleeding appears after subsequent bounces. But “instant radiosity” seems to me like light cuts with one bounce calculated.
As you have said, the temple animation is breathtaking. Not only in quality, but in the fact that most “instant light solutions” sucks because of flickering in the animation.
Wasn’t Broken (sorry If I got the wrong dev!) working on something called “Image based lighting” that was another way of faking this? It was supposed to be fast, but I never really saw any details on it.
i think he is still working when he has time.
that is what he told me ast time i asked him.
Yeah, that’s right. Currently, the first (spherical harmonics) method of IBL I’ve worked on functionally works just fine, and is very fast, especially combined with AAO.
However the project that I needed it for got cancelled, so any further work on it is just in my spare time, at a low priority. I want to finish a raytraced importance sampled method (to get specular shading and directional shadows) but the other main thing is that the integration of this sort of thing in the UI (ambient/indirect lighting/GI etc etc) is quite a bit of an undefined mess right now, and I think we really need some kind of organised framework that allows for future growth. i.e. how to organise shading (from sky, from HDRI, from indirect light bounces, etc), or gathering methods, or things like possible irradiance caches, indirect lighting like the shaded AAO, or photon mapping, or instant radiosity.
Right now there’s not a clear path to get this organised, in a coherent, usable and clear way, and I haven’t had much time to think about it myself. I hope as part of the lightcuts project David/Brecht/myself/anyone else can have a think about how best to move forward on this. As for the IBL itself, well I’m curious to see how it pans out - the lightcuts project might provide a much better solution for IBL than mine, in which case, that would be great 