Lights are heavy, Better idea is need !

[ahmadi]

Hi
I have a city map, its big (consider the New York city).
My sun are moving from east to west.this mean that my city are moving from the day to the night, in the night, there is no sun, i must enable my city lamps.
But enabling ~1500 Lights in a scene to showing lighting of the lamps is impossible!!!
Also if i replace 15 Lights in my scene instead of 1500, I will lost 200 FPS of my scene!
This mean that 15 Lights are also heavy(have big process)!
Maybe you offer i use another texture for my city meshes for the night, but this need a loading when the night is comming ! creating the texture is easy, i can use RenderToTexture idea, but loading is't good!
I need any idea that help me i simulate the night lighting in the city without heavy process or loading.

Note: Im using alpha sprite for showing the lamps position.
Thank you for your attention.

[lXciD]

use shader that support directional light.

i think u might wan to consider paging ur cityscape.

[sivael]

You can always create a sprite+mesh(directonal effect) like a crossed triangles, a cone or something like that with some kind of additive blending, or just render these to a buffer(intensity based on the depth), apply bloom and put it on the scene.

Lights should be used only for the closest effects - those with a lot of detail needed:)

[ahmadi]

You can always create a sprite+mesh(directonal effect) like a crossed triangles, a cone or something like that with some kind of additive blending, or just render these to a buffer(intensity based on the depth), apply bloom and put it on the scene.

The result is in following screenshot, its good idea but not for city lamps or im not understand what you mean.:


I need following result :

[eugen]

You should use static lighting whenever needed (lightmaps). You wont be able to achieve dynamic lighting with that much amount of lights period if you want to have a broad view of the city altogether. Otherwise prioritize lights and only enable those near your character when you narrow your view at the street level.

[syedhs]

The problem with night scene is because there are so many light sources. Many light sources will lead to many shadows for each car and therefore, it is very slow. For my own night scene I simply disable dynamic lighting altogether. Static lighting (lightmap) is baked onto the roads, and the only other lights are the ones from other vehicles's headlamps.

The other improvements that you can consider is to use some kind of environment map - it is not really environment map, it basically blends the vehicle texture with small portion the big texture of the scenery. It results in the
1) cars getting blackened when entering dark tunnel,
2) cars getting lighted up when they are under lamp post.

The implementation detail is in ShaderX2 book by Wolfgang Engel. It is very fast and add a lot of realism.

[madmarx]

Static lighting.


Or light backing in realtime (you calculate in realtime only once parts of your ground lighting, and then you bake it at run time, and you don't calculate everything at each frame).

Or deferred shading with advanced scene management.

[ahmadi]

Using baked texture, mean that i must replace all of object materials at nights, there is two problem:
1) reloading the objects material need loading !
2) i must design two map (one is default map, two is night map)

I have one idea, but i don't know how can i do it:
We can use one circle-plane on ground (the plane is white and is blended on ground surface), its invisible in the day, and is visible in the night.
But the problem is here that the ground of map is not flat! its non-flat, it consist from some mesh(are not flat). How can i say the circle-plane to render on the non-flat ground. (its same as i stencil the circle-plane on the ground).
Is the idea possible? can i stencil the while circle-plane on the ground?
Thank you for your attention.

[madmarx]

Circle plane as mesh is dangerous:
you will likely get Z fighting even if both circle and ground are completely flat.

For stencil, I have no idea right now.

[gamedboy]

you can render the circles on a separate render target, then using projective texturing on the terrain

[ahmadi]

Circle plane as mesh is dangerous:
you will likely get Z fighting even if both circle and ground are completely flat.

Solving Z fighting is easy, i can remove Z Fighting if i disable Depth Writing of the circle-plane.

[ahmadi]

you can render the circles on a separate render target, then using projective texturing on the terrain

Sound likes good, but i have never said it before, Can you show me a startpoint or a tutorial or any sample?

[gamedboy]

it is quite simple to projective decal in
http://www.ogre3d.org/wiki/index.php/In ... Tutorial_6
just set the camera to be high up looking down

[Kojack]

Are most of the lights basically downwards facing street lights?
What I'd try is this:
- Build a texture to cover the area of the city. Each pixel represents if there is an active street light at that position.
- Every shader includes a lookup in the street light texture to see if the current pixel (or vertex, could be a shader model 3 vertex shader with texture lookup) is within the region of an active street light, and performs the usual lighting equation.

You could store more info in the street light texture so everything doesn't have to be grid aligned. For example, each pixel's alpha could be the light brightness, then the rgb could be the 3d position of the bulb within the pixel's region (a pixel might correspond to a 10x10m area of the city, the rgb would let you place one light anywhere within that region).

Hmm, if I wasn't so busy (and I've already had 2 blackouts in the last 3 hours) I'd try it myself, sounds like a fun idea.

[warmi]

Are most of the lights basically downwards facing street lights?
What I'd try is this:
- Build a texture to cover the area of the city. Each pixel represents if there is an active street light at that position.
- Every shader includes a lookup in the street light texture to see if the current pixel (or vertex, could be a shader model 3 vertex shader with texture lookup) is within the region of an active street light, and performs the usual lighting equation.

You could store more info in the street light texture so everything doesn't have to be grid aligned. For example, each pixel's alpha could be the light brightness, then the rgb could be the 3d position of the bulb within the pixel's region (a pixel might correspond to a 10x10m area of the city, the rgb would let you place one light anywhere within that region).

Hmm, if I wasn't so busy (and I've already had 2 blackouts in the last 3 hours) I'd try it myself, sounds like a fun idea.

Yeah, it is called lightmapping

[Kojack]

Yeah, it is called lightmapping Smile

No it isn't.
Thousands of moveable dynamic lights with localised coverage stored in a spacial lookup table which just happens to be stored in a texture for easy shader access isn't light mapping.

Maybe I didn't explain in enough detail (I'd already lost one post on this forum just half an hour earlier when a second blackout hit the house as I was typing, so I rushed a bit).
The street light texture isn't applied to objects as a light map. It's being used as a lookup table where each texel represents the presence and position of a light within a square region of the world. The lighting shader performs normal dynamic per pixel lighting, except that instead of being told where the light is directly, the shader looks up the street light texture to get the 3d position of a nearby light.

[jacmoe]

That would be a really cool Ogre demo!

[ahmadi]

The street light texture isn't applied to objects as a light map. It's being used as a lookup table where each texel represents the presence and position of a light within a square region of the world. The lighting shader performs normal dynamic per pixel lighting, except that instead of being told where the light is directly, the shader looks up the street light texture to get the 3d position of a nearby light.

Thx,Good idea, but also we must consider following issue:
for each material, we need to find nearly lights, there is no real lights, we must look on "street light texture" to detect is there any light near here or not? but where is "here"? we must look on vertex positions, adjust "street light texture" and do a sequential search on pixels, and vertices.
Im not sure its possible to maintain lookup table in shader languages or no.
Sequential search need process !
If i'm understand, result is following pseudo code:

Code: Select all

For each material do
{
    r=FindRegionOfMaterialOwner(mat)
    lightPosList=FindNearestLightPos(r)
    for each pos in lightPosList do applyLighting(mat)
}

both "FindRegionOfMaterialOwner" and "FindNearestLightPos" have inside loop and let the scene materials count is N, the street light texture size is 1024*1024, the algorithm is approximatly 1024*1024*n*LightsCount steps !
i think it need heavy process.
I don't know how possible to use lookup table in shader language, because lookup table can reduce the algorithms steps to n*LightsCount.
Thank you for your attention

[Kojack]

While supervising a maths exam today I knocked up a quick test of my technique.

Instead of doing the full lighting equation I did a circle renderer. Replacing that bit with light is easy, I just wanted something easier to test. Effectively each circle is currently the area under a light.

I made the street light lookup texture 16x16. This means there can be 256 lights. The red channel of each pixel represents the radius of the light spot within that cell (with the proper version I'd use rgb as offset position and alpha as brightness).

Here's a pic of it running in Rendermonkey:


Here's the street light lookup table:


And here's the shader source (note: inefficient, hacked together, probably horrendous crap, but it's working. Just an experiment):

Code: Select all

float offsety;
float offsetx;
sampler2D Texture1;
sampler2D baseMap;

struct PS_INPUT 
{
   float2 Texcoord :        TEXCOORD0;
   float3 ViewDirection :   TEXCOORD1;
   float3 LightDirection:   TEXCOORD2;
   float3 Normal :          TEXCOORD3;
   
};

float4 lookup(float2 mappos, float2 offsetpos)
{
   float3 lightpos;
   float4 c = float4(0,0,0,1);
   float4 streetlightcell      = tex2D( Texture1, offsetpos );
   float rad = streetlightcell.r/16.0;
   if(rad > 0)
   {
      lightpos = float3(
      (floor(offsetpos.x*16)+offsetx)/16,
      0,
      (floor(offsetpos.y*16)+offsety)/16);
      float3 lightvec = float3(mappos.x,0,mappos.y)-lightpos;
      float ln = length(lightvec);
      if(ln<rad)
      {
         c.rgb = float3(1,1,1);
      }
      
   }
   return c;
}

float4 ps_main( PS_INPUT Input ) : COLOR0
{      
   float4 diffuse = lookup(Input.Texcoord, Input.Texcoord+float2((1.0/32)*-1,(1.0/32)*-1))+
   lookup(Input.Texcoord, Input.Texcoord+float2((1.0/32)*0,(1.0/32)*-1))+
   lookup(Input.Texcoord, Input.Texcoord+float2((1.0/32)*1,(1.0/32)*-1))+
   lookup(Input.Texcoord, Input.Texcoord+float2((1.0/32)*-1,(1.0/32)*0))+
   lookup(Input.Texcoord, Input.Texcoord+float2((1.0/32)*0,(1.0/32)*0))+
   lookup(Input.Texcoord, Input.Texcoord+float2((1.0/32)*1,(1.0/32)*0))+
   lookup(Input.Texcoord, Input.Texcoord+float2((1.0/32)*-1,(1.0/32)*1))+
   lookup(Input.Texcoord, Input.Texcoord+float2((1.0/32)*0,(1.0/32)*1))+
   lookup(Input.Texcoord, Input.Texcoord+float2((1.0/32)*1,(1.0/32)*1));
   diffuse = clamp(diffuse,float4(0.3,0.3,0.3,1),float4(1,1,1,1));
   return tex2D(baseMap,Input.Texcoord)*diffuse;
}

So that's effectively 256 lights acting on one mesh with only a single pass shader and no loops.

Of course the limit here is the cells. The world in the pic above (a plane, but could be anything) is divided into 16x16 cells. Each cell can only contain 1 light. At the moment I've hard coded each light to be in the middle of the cell, but the position within a cell could be stored in the cell colour. The lookup() function is called 9 times per pixel so you can get lights which leave their cell and affect the cell next to them. So while there's only 1 light per cell, there can be up to 9 lights affecting a cell (1 inside the cell, and 8 surrounding it).
By locking the texture and playing with the colours of pixels, you can make the lights turn on/off or change radius (or move in the full version) in real time.

If I get time tomorrow, I might make a real lighting demo in Ogre, and bump the lights up to maybe a few thousand.

[ahmadi]

...
If I get time tomorrow, I might make a real lighting demo in Ogre, and bump the lights up to maybe a few thousand.

Very nice idea, Im very interesting to see your ogre demo (but please incorporate non-flat objects for ground and multi objects in the scene)
Im not success to play with your shader, Here is my RenderMonkey project, seems that my project need configs !?

http://www.megaupload.com/?d=OE281ZTB

Or maybe i have no enough RenderMonkey knowledge yet.
Thank you for your attention