Page 1 of 1

### Idea for lighting

Posted: Thu Sep 19, 2013 3:17 pm
Greetings!

I have a idea on how one can implement lighting of sorts :

First we need to have a emitter of light and give it some important values :

Code: Select all

``````love.load()
MyEmitter = {}
MyEmitter.xPos = 2
MyEmitter.yPos = 2
MyEmitter.angle = 45 --This is important as it sets the direction the light is emitted
MyEmitter.max_angle = 15 -- This is the maximum angle the light will be emitted at, the true maximum is MyEmitter.angle+MyEmitter.max_angle
MyEmitter.min_angle = -15 -- This is the same as above but is the minimum, thus : MyEmitter.angle+MyEmitter.min_angle
MyEmitter.intensity = 50 -- this is the maximum range that the light will be traveling
end
``````
Now we need to have a function that takes the emitter This is the main body :

Code: Select all

``````function EmitLight(emitter)
tbl = {}
points = {}
increment = emitter.angle+emitter.min_angle
break_Loop_angles = false
while(increment < emitter.angle+emitter.max_angle) and not break_Loop_angles do -- here we loop until all angles between the max and min are used.
for dx = 0,emitter.intensity do -- loop until intensity maxed out
local x_check = (dx*math.cos(increment))+emitter.xPos -- this gets the xPoint of the current angle at the current distance(dx)
local y_check = (dx*math.sin(increment))+emitter.yPos -- this gets the yPoint of the current angle at the current distance(dx)
table.insert(points,x_check)
table.insert(points,y_check)
end
increment = increment+math.rad(1) --- TAKE NOT OF THIS LINE FOR BELOW
end
return points
end
``````
OK so notice that important all caps "TAKE NOT OF THIS LINE FOR BELOW" ?
This line i found to be important as the LOWER the number we increment by the more filled and accurate our cone of light is.
I found that 0.1 is abit better, 0.01 is incredibly good but extremely slow and 0.001 is absolutely filled cone but can just about crash the program!

Ok so we want to render our cone :

Code: Select all

``````love.update(dt)
if love.keyboard.isDown("f") then
myCone = EmitLight(MyEmitter)
end
end

love.draw()
if myCone then
love.graphics.polygon("fill",myCone)
end
end
``````
NOW that it works we can maybe improve on it (because it really DOES need optimizations)

Firstly if we pass a table of objects to check against we can make some light get obstructed. During the intensity(dx) loop we loop through all objects and compare the x/y_check with that objects x,y. Should they match then the point isnt added to points and we move onto the next angle since no more "light" will be beyond that point.

Next is focus on the increment. Setting it lower makes the cone more filled, yet anywhere below 1 (and even 1) just lags out alot.
I have absolutely no idea how to combat this.

Lastly there is the drawing of the cone, when using lower increments like 0.1 etc the drawing of the points is insane.
To combat this i think taking all the points and then converting them into a more clean poly gon that fills in just as muh would be a good way to optimize this. It may even help with needing lower increments for more filled cones.

So far im unsure on whether this is a good wayto look at for lighting idea, but its one i think is pretty different from what i know. Also i think what i do in EmitLight is similar to rayCasting but im unsure...

Anyways, please feel free to discuss this and provide feedback, BUT remember : my goal above was to work on a way to make light in games and this is also a practice session involving love.physics and angles.
IF any explanation is required for anything regarding my idea is needed ill gladly provide.

-end-

### Re: Idea for lighting

Posted: Thu Sep 19, 2013 5:30 pm
There's way to do it easier and faster: raycasted shadows.

What do you do:
0) render the scene lit
1) traverse each light source
2) in it, traverse each shadow source and build a raycasted shadows, render them to stencil buffer
3) then render a light texture (be it a spot light, a beacon, a flashlight or whatever kind of light you have) using previously generated stencil buffer with a shader that emulates light casted onto the surface
4) PROFIT!

### Re: Idea for lighting

Posted: Thu Sep 19, 2013 6:16 pm
raidho36 wrote:There's way to do it easier and faster: raycasted shadows.

What do you do:
0) render the scene lit
1) traverse each light source
2) in it, traverse each shadow source and build a raycasted shadows, render them to stencil buffer
3) then render a light texture (be it a spot light, a beacon, a flashlight or whatever kind of light you have) using previously generated stencil buffer with a shader that emulates light casted onto the surface
4) PROFIT!
This would have been a good idea if we were back in 1990s. Don't use stencil buffer and other fixed function pipeline relics of the past. Use the shaders instead. Idea remains the same but switch to render targets instead of stencil buffers.

### Re: Idea for lighting

Posted: Thu Sep 19, 2013 6:30 pm
Does the above method involve GLSL? I am somewhat trying to learn it slowly.
And otherwise ill try to make sense of what was suggested and implement it, Thanks for the reply.

Anyways, i now need to look into my other projects such as rotating the environment around a player when he turns.

### Re: Idea for lighting

Posted: Thu Sep 19, 2013 6:39 pm
Yes it does. I'd suggest learning GLSL 1.2 (the one that Love2d uses) with a book. You can test your shaders online with www.shadertoy.com

### Re: Idea for lighting

Posted: Thu Sep 19, 2013 6:54 pm
I see you didn't read my post through, but okay.

Stencil buffer is nowhere near being obsolete. It's an extra buffer used for complex graphics operations that can't be easily done otherwise (read: allows MUCH faster rendering), it's absolutely indated and will remain such for long time.

### Re: Idea for lighting

Posted: Thu Sep 19, 2013 7:29 pm
As it turns out surprisingly stencil buffers are still in use sometimes in 3d graphics.

Speaking about performance it's a more difficult subject. The way you operate on your stencil buffer will dramatically affect its performance (the way stencil buffers are cached). It might be horribly slow or quite fast. Here is a good read explaining how to work efficiently with Z-testing and Stencil Buffers.

http://www.gamedev.net/topic/593248-ste ... try4761442