The idea is to have hundreds or thousands of dynamic light sources to simulate street lights in a city environment, without the massive performance hit of rally using that many lights.
This time it's really in ogre (not rendermonkey), with a city road mesh I found in the google 3d warehouse.
The fps display (fraps) dropped by 30-40fps during screenshots, so the full view shot was about 940fps. That's with 256 simulated point lights doing per pixel lighting on a single mesh.
Chucking 256 real ogre point lights at the same mesh with pass per light iteration and only bare vertex lighting was 11fps. It would be even slower with per pixel lighting.
With only 8 lights it was 300fps.
The cool thing about my shader is that there should be little performance hit for increasing the light count.
Here's the same scene with 4096 lights:
It was running at 925fps (again, the fps drops during a screenshot).
Don't worry about the road being black, I spawned the lights via code and they are all close to the ground, below the height of that middle road segment.
This isn't a light map, the lighting isn't baked. These lights are dynamic and could move or change brightness. They are doing a full per pixel N dot L style lighting with some distance fading.
Here's how it works:
I create a manual texture with a res of 16x16 (that gives 256 lights, make it 64x64 for 4096 lights, etc).
This texture will be mapped over the entire world, effectively dividing the world into x 16x16 grid of cells.
Each pixel of the texture represents the position and brightness of a single point light. The alpha of the pixel is brightness, the rgb of the pixel is the xyz position as an offset from the current cell's corner, and a range of one cell. So the colour 0xff800580 would be a pure white light slightly above the ground and in the middle of it's cell.
So each cell can only contain one light, but that light can be anywhere within the cell.
In my vertex shader, I assign a world position (scaled so 0-1 covers the whole world) to each vertex as a 3d texture coordinate. I also pass the normal in.
In my pixel shader, I read the interpolated world position of each pixel and pass it to a cell lookup function. This function takes the world pos, works out which cell the pixel is within and looks up the texture to get the position and brightness of the light for that cell. I calculate where the light is in world space and do the standard lighting equation on it to get a diffuse colour, which it returns. This is enough for a single light to affect each cell, but that looks crap when a light is near the edge (since the light can't affect the next cell, so you see a hard cutoff edge of light). So instead I call the lookup function 9 times per pixel, to get the total lighting from the 3x3 cells around the current pixel. This means up to 9 lights are affecting each pixel. I can boost the speed of the 4096 light demo to 1300+fps if I only do a single lookup instead of 9, but then lights can't affect neighboring cells (could be ok if you design the world right).
To dynamically change lights, each frame you can lock the texture, modify any pixels you want and unlock.
Of course the obvious limit here is the one light per cell restriction. For street lights at night, that should be fine, most street lights are spaced apart so there isn't much overlap. You could always make several textures so you can look up multiple lights per cell.
No thought has gone to shadows, I'm trying to pretend they don't exist.
A spotlight would probably work better than a point light, I might change it for the demo.
I want to fix the shader and code a little (moving lights, moving objects, etc), then I'll give it out.
