Thx for the tip with the nVidia SLI guide, will look through it some time.

Let´s see if I understand that lightcut stuff correctly:
First you build a global light tree, which is an ordinary binary tree with the original lights as leaf nodes and every other node being a possible replacement for its children. After that, I have to choose which nodes (lights) of the tree to use for a specific part of the picture, which is the lightcut.
If this is correct, I think the only problem would be that I would need to calculate an error criterion. In the paper the lightcut technique seems to pay off only for a magnitude of light sources that I hope I´ll never reach. However I think that this is because they choose a quite small error threshold, right?
If I allow a higher error to occur the lightcut should be effective for a smaller number of lights.

Now, assuming I have an error criterion algorithm set up, I should be able to build that light tree, choose a lightcut for every quadtree node and store it there (I guess this should be doable when loading a map, shouldn´t take that long I assume).
After that every object in that quadtree node should be rendered using that lightcut. The only problem with this are objects that lie in two or more quadtree nodes. However, since the lightcuts of neighboring quadtree nodes ought to be similar it should be possible to determine a "tradeoff" lightcut which is good enough for both most of the time.
Perhaps using three different lightcuts (for the three light LOD "groups") would be feasible. However that would make the case of an object lying in two or more quadtree nodes even more ugly, having to get that "tradeoff lightcut" three times.

Somehow I get the feeling that I´m again doing too much in theory without implementing and trying it ;)

Quote:Original post by matches81
Somehow I get the feeling that I´m again doing too much in theory without implementing and trying it ;)

Theory is good though, as is design... sucks to have to rewrite wads of code. If I could do only theory and have the computer "just understand", I'd be a happy person :)

It seems that you have the idea of light cuts... I'm not totally sure that the paper used it in real time, so perhaps something similar with a courser approximation is in order. There are probably optimizations to be made with fewer sets of lights as well. In any case I'd be interested in seeing/hearing about your results!

Quote:Original post by AndyTX
Theory is good though, as is design... sucks to have to rewrite wads of code. If I could do only theory and have the computer "just understand", I'd be a happy person :)

Well said ;) I´ll have a try on the implementation of lightcuts and tell you how it worked out as soon as I´ve got the time to actually do it. Thx for your input so far.

Quote:Original post by zedzeek
its one of those ideas that seem good in theory + then u try it and its yuck
the problem is say u have a person walking through the light area, if u dont update each visual frame u can easily tell that the shadow on the ground is not in sync with the shadow caster, it looks terrible, not to mention selfshadowing is totally screwed up as well, as the polygon depth comparrision of camera scene vs light scene aint equal

I could understand the self shadowing issue, but I really don´t see how you could notice that the shadows are out of sync if the shadows are updated at 20FPS (or more), which means they´re out of sync by max 0.05secs. I mean, yeah, they are out of sync, but 20 FPS is enough to give the illusion of a rather fluid animation.

Quote:Original post by matches81
Thx for your input so far.

My pleasure; efficient lighting computation of fully dynamic scenes is of personal interest to me, so I'd love to see how your results turn out.

Quote:Original post by matches81
I mean, yeah, they are out of sync, but 20 FPS is enough to give the illusion of a rather fluid animation.

True, but I suspect that componded with the rasterization/projection aliasing of shadow maps, it would get fairly obvious :) If you can produce totally smooth and anti-aliased shadows you can probably get away with updating them less often - but if you can do that efficiently, please let us know how!