tanema / light_world.lua Goto Github PK

returns true/false depending on whether the body is in shadow.

Attempts to use getPosition() on a polygon (or rectangle) gives:

body.lua:114: attempt to index local 'self' (a nil value)
body.lua:114: in function 'getPosition'

Attempts to use setPosition() on a polygon (or rectangle) gives:

body.lua:105: attempt to index local 'self' (a number value)
body.lua:105: in function 'setPosition'

I added a print() to see that "self" is zero. The object is at 17/2 x 27/2 (if you're looking at the center), or 0 x 0 from the top left corner.

While requiring this library en error occures while loading phosphor.glsl:
love2d 11.1, Windows 10

Error validating pixel shader code:
Line 128: ERROR: '_tex0_' : undeclared identifier 
Line 128: ERROR: 'texture2D' : no matching overloaded function found 
Line 128: ERROR: 'texture2D' : no matching overloaded function found 
Line 128: ERROR: 'texture2D' : no matching overloaded function found 
Line 128: ERROR: '' : compilation terminated 
ERROR: 5 compilation errors.  No code generated.


Traceback

[C]: in function 'newShader'
lib/util.lua:78: in function 'loadShader'
lib/postshader.lua:37: in main chunk
[C]: in function 'require'
main.lua:8: in main chunk
[C]: in function 'require'
[C]: in function 'xpcall'
[C]: in function 'xpcall'```

with no object involves, only with ambient light {0,0,0}, this library's draw call takes up about 1500MB of memory.

Whenever I create bodies in love.load I get normal shadows as on first screenshot. But whenever I create bodies from other places in code it gives me situation like on second screenshot.


I create body for each square (have no idea how to optimize this), the blue square in center is light source.
There's no problems with global variables.
Any suggestions on the problem?

I think this project needs a change log in order to stay updated with the changes.

Unless you're intending the alternate spellings?

I'd fix the spellings myself but I am a bit timid about interfering even though I already am, haha.

It's been bugging me since I stumbled across this but I forgot to mention it. I should've mentioned it sooner so people don't start using this too much before it gets fixed.

I just downloaded the examples to test this out and it seems that when shining light on an object with a normal map, the light is on the correct size on the x-axis (left and right), however if the light is below the object, the top half lights up, and vice-verca.

Hey, I made a game using this library, and made a single light. I ran the game and the game crashed after a few seconds, having racked up over a GB of VRam usage. I was really hoping to use this in my game aswell :(

Load code (w/ light):

function game:init()
	Textures = {}
	Textures.tile = love.graphics.newImage("assets/images/kitchen_tile.png")
	
	Tiles = {
		Textures.tile
	}

	Cam = require "libs.camera"
	
	-- vars
	Level = {
        {1, 1, 1, 1, 1, 1, 1, 1, 1, 1},
        {1, 2, 2, 2, 2, 2, 2, 2, 2, 1},
        {1, 2, 3, 4, 5, 5, 4, 3, 2, 1},
        {1, 2, 2, 2, 2, 2, 2, 2, 2, 1},
        {1, 1, 1, 1, 1, 1, 1, 1, 1, 1}
    }
	
	tile_width, tile_height = 250
	
	Lighting = Light({
		ambient = {55,55,55},         --the general ambient light in the environment
	})
	
	-- Scene Objects
	Lighting:newLight(200, 200)
end

draw code:

function game:draw()
	love.graphics.push()
		love.graphics.translate(0, 0)
		love.graphics.scale(1)
		Lighting:draw(function()
			for i,row in ipairs(Level) do
				for j,tile in ipairs(row) do
					if tile ~= 0 then
						love.graphics.draw(Textures.tile, tile_width * j * 0.4, tile_width * i * 0.4, 0, 0.4, 0.4)
					end 
				end
			end
		end)
	love.graphics.pop()
end

https://www.youtube.com/watch?v=sIiSpLL-sAg
This video is the sort of results I am hoping for, however, the lighting library that they use is hopelessly outdated - I tried updating it/fixing it for a solid 30 minutes and barely got any results. I would like to achieve similar results with this more modern lighting system, but I have NO IDEA how to achieve such pixellated light as in the original.

Would it be possible to add the Z axis in the setPosition function of the Body like it is on Light.

Let say I have a room with walls, a player in the room and a light.
If I don't set the Z on the light and the player walk over it, it hides the light.
The Z position on Light fix this issue, but creates another one, all the bodies have the same Z, if the light is over the player, it is also over the walls and therefore goes outside the room and brighten the rest of the map as well.

The solution would be to allow a Z position on the bodies as well so we could for example put a Z value of 5 on the light in the room, the player would have something like 2 and the walls would have 8.

This way the light would not be hidden by the player if they are on the same position but would not go outside the room because the walls would be taller

copied from the love forums:

I have been using light_world for a while now, though to date I've been using it with statically-placed lights that do not move. Lately I am discovering a really odd behavior when I want to selectively decide if a light is visible or not.

The logic is rather simple:

1. in love.draw, set all lights to not visible ( setVisible(false) )
2. for each tile to render, see if that tile contains a light. if it does, update its relative position and make it visible

This does not work at all. As soon as the light has been made invisible, it will never appear again. Dumping the contents of the object, you can clearly see the light SHOULD be appearing. It'll look something like this:

[code]        (*)     l       |
        z       =>      1
        visible =>      true
        red     =>      1
        green   =>      1
        blue    =>      1
        glowStrength    =>      0
        glowSize        =>      0.1
        x       =>      1013
        y       =>      631
        angle   =>      6.2831853071796
        direction       =>      0
        range   =>      110
        smooth  =>      1
        is_on_screen    =>      true[/code]

I can immediately invoke update() on the light world or not, it doesn't make a difference. What DOES work is if I completely destroy the light object and then immediately re-create but, but this is so slow as to be totally unusable. I have no idea why the library is behaving in this way, and it seems to have not been updated in a long time, so I guess this is a long shot, but I'm hoping someone here might be able to help.

Here's a bit of code that determines if a light is going to be drawn or not:

[code]          if (maps[room][layer][roomx][roomy].fn) then -- tile has a light
            if (global.state.screen.light) then
              local lsdx = rangeXmax - mx + 1 -- tracking which portion of the map is going to be drawn
              local lsdy = rangeYmax - my + 1
              if not(lights) then lights = { } end
              local id = room .. maps[room][layer][roomx][roomy].uid --creating a unique identifier for the light
              if not(lights[id]) then -- need to re-create this light
                print("creating light in room " .. room .. " at position " .. lsdx .. " " .. lsdy .. " " .. ((spreadX*64)+offsetX-64) .. " " .. ((spreadY*64)+offsetY-64))
                local ld = f_ed_get_light(lightsdata[maps[room][layer][roomx][roomy].fn].fn) -- describe the light
                local offset_x, offset_y = 0, 0
                if ld[7] then offset_x = offset_x + ld[7] end
                if ld[8] then offset_y = offset_y + ld[8] end 
                lights[id] = light:newLight(((spreadX*64)+offsetX-64) + offset_x, ((spreadY*64)+offsetY-64) + offset_y, ld[1], ld[2], ld[3], ld[4])
                if ld[5] then lights[id]:setAngle(ld[5]) end
                if ld[6] then lights[id]:setDirection(ld[6]) end
              else -- light was already made, update position
                --print("updating light " .. id .. " in room " .. room .. " at position " .. lsdx .. " " .. lsdy)
                local ld = f_ed_get_light(lightsdata[maps[room][layer][roomx][roomy].fn].fn)
                local offset_x, offset_y = 0, 0
                if ld[7] then offset_x = offset_x + ld[7] end
                if ld[8] then offset_y = offset_y + ld[8] end
                lights[id]:setVisible(true)
                lights[id]:setPosition(((spreadX*64)+offsetX-64) + offset_x, ((spreadY*64)+offsetY-64) + offset_y)
              end[/code]

If I simply run that code as-is, the lights work, but as soon as you move, many other lights will start to be be created and will never get cleaned up. I tried many, many, many methods to clean them up, and none short of destroying the light worked. Using this method below causes all the lights to go invisible and never return, no matter how many times you make them visible again afterward:

[code]
        if (global.state.screen.light) then
          for k,v in pairs(lights) do
            if (lights[k]) then
              lights[k]:setVisible(false)
            end
          end
        end[/code]

okay, i have confirmed lightworld rotates (sort of), if i put in the love.graphics.rotate into the actual lightworld function bit, in my code, in ee_engine.lua:

lightWorld:draw(function() --this is the lightworld pass

            love.graphics.rotate(camera.rotation)

            for _,entity in pairs(self.entities) do
                entity:lightdraw()
            end
        end)

i found if i omit, the scaling and translation, it is the closest to working correctly.

i found also, the sequence is important, so lightworld has received the scaling and translation, it is important other draws follow the same sequence (rotation MUST be last)

this investigation suggests the code on the main page might be wrong?? you are not supposed to scale and translate in love.draw()

Please, have a look at my code, at least try using the controls to see. It has WSAD directions, QE scale, and RF rotate.

You can switch on (in ee_engine.lua) a non-lightpass, with Engine.draw_non_lightpass = true

I have managed to get both passes to exactly match each other.

Sorry i am so long winded, the fundamental issue is, the lights do not rotate with the scene, if you rotate my (attempted) camera, you will find the lights do not rotate (so lightworld sprites rotate fine, it's lights do not).

EntityEngine.zip

This little framework, i was hoping to integrate all this stuff, light, physics, camera, and eventually UDP, into one thing bases on the usual sort of Unity style component model. The best bit so far is the physics are optional :)

Summary of code:
main.lua
ee_engine.lua --the singleton
ee_entity.lua --the in game objects

Hi there,
I'm not sure what can be done regarding the performance issue with this library...
When working with large scenes (few thousand normal-mapped objects + shadow-casting polygons) in 1080p two things happen:

1. Memory gets filled up to the point where machine starts swapping and it basically freezes within seconds. I have to call garbage collector manually to keep it around ~200MB all the time

2. Adding just a few light sources slows down game to a crawl - single digit FPS count.
   I've tried it on quite a few machines and even dedicated, high-end gaming rig had problems...

Are there any things I should check on my side? I've noticed that the "complex" demo provided yields similar results when adding many light sources and shadow casters. It probably - probably - gets around better because of much lower resolution and smaller scene size.

Thanks and happy new year!

Just the bae library, I'm attempting to run the short example. Google Pixel 2 XL, Android 8.0.1.

If anyone could provide a fixed version or explain how to fix it, that'd be great.

It seems that shaders are not compatible with GLSL ES, I attempted to run an example on adroid and it was not able to create shaders.

Again, just a convenience thing.

Due to some code change, method drawShadows() at file init.lua fails on line 160:self.shadowShader:send('lightRange',{light.range * s}).

This happens because self.shadowShader:send() should receive a number instead of a table.
Changing the line to 160:self.shadowShader:send('lightRange',light.range * s) solves the issue.

Screenshot attached.

I've set ambient to black, then I run the complex demo. I left click twice(adding standard polygons) one up and to the left of the other.
When I move the light to the top left, it casts a shadow down on to the bottom object but the bottom object is still drawn (rather than being hidden) - Is this correct?
Example:
http://imgur.com/a/cdYyc

I assume this does not seem to support rotation?

does anyone have any idea how hard it would be to implement rotation?

It's gotta be a bug at this point. I set up a new environment to test in to be sure.

Screenshot: http://i.imgur.com/JePSYOX.png

Program: https://gist.github.com/Guard13007/07af73daee17d8fda83a

The engine was of course stored in a folder called "LightWorld" and loaded correctly.

I am pulling my hair out trying to understand how to use this.

There is no documentation linked to from here that I can see, and the bitbucket docs are out of date.

I've managed to get it running, though I'm not quite sure what I'm doing, and with rectangles, I can't seem to get them to generate anything other than the default size (that may be another bug but I can't know that unless I know how I'm supposed to create them).

Right now I have lightWorld:newRectangle(100, 100, 17, 27) which I expect to create a 17 by 27 pixel rectangle, but it creates a 64 by 64 pixel rectangle.

Hi there,

I noticed that Y-axis lighting is reversed.

What I want: http://onepixelahead.de/love2d_polyshadow7.png
What I get: https://i.imgsafe.org/0f581878af.png

Image "front" should be lighten up when "above" light source, not the other way around as it currently is.

EDIT:
pgimeno from Love2D forums wrote:

I see now. What LÖVE version is that library for, and what version is your program for? I ask because there was a swap of the shader's Y coordinate at some point, IIRC between 0.9.2 and 0.10.0, and I wonder if that's at play here.

Edit #2:

vec3 normal = normalize(vec3(normalColor.r,invert_normal ? 1 - normalColor.g : normalColor.g, normalColor.b) * 2.0 - 1.0);

swapped with

vec3 normal = normalize(vec3(normalColor.r,invert_normal ? normalColor.g : 1 - normalColor.g, normalColor.b) * 2.0 - 1.0);

gets the job done!

When using a camera that pans shadow-casting bodies off-screen, the shadows stop calculating for those bodies eventually. At first I thought it was an issue with my scaling engine and so I was puzzling over it for a while. This came about from an effort to create a 'sun' with a near-infinite radius across many bodies, hence the desire to create large sweeping sunbeams and shadows across a larger landscape. The ambient light was turned way down for this example to highlight the contrast:

But then going in and testing this behavior in the example library under 'gamera' created the exact same issue. Watch the yellow light when i pan the object offscreen:

Presumably there's some memory-management happening here that is causing bodies to be ignored when off screen.

As seen in the first example, the impact of this can grow rather large with a larger light radius and many shadow bodies.