Let There Be Light 2

[mashedtatoes]

Anybody run into this problem?



This is a trace over where the occluders are. The only light source is the red square.



The first occluder (the yellow line directly above the red square) is not stopping the light. It still does this if I make the light smaller (half the size). As long as the edge of the light gets past the opening, light shows through.

I also just noticed you can see occluders through other occluders when renderLightOverShape is set to true

[Breush]

Hi everyone,

I noticed there was no change to 222464's repository of LBTL2 for the last few months and that none of the pull requests were accepted.

So I decided to fork LTBL2 in order to improve it.
This message is for any developer who wants to help the project to grow a little bit faster:
https://github.com/JumpingToasts/LTBL2

My main concerns are:

• Speed. I'm starting to improve the overall performance even if it requires to change the library interface. My aims are better data locality and as much as precomputing we can so that the render() loop can be the lightest of all. I think this is critical for games to run smoothly.
• Abilities. I'm really interested about what can LTBL offer to the user. Today, I added a feature to handle normal maps. An example can be found in the example folder.
• Interface. I was not really a big fan of original LTBL2 interface, as shared pointers add some computing penalty and no (easy) precise control of memory. I'm fully open to suggestions in order to improve the user experience.

I'll be glad to receive suggestions or (even better) pull requests via the repository issue system.

Please note that this version is in active development, and really not ready for use.
Thank you for reading.

[DarkRoku12]

Hi everyone,

I noticed there was no change to 222464's repository of LBTL2 for the last few months and that none of the pull requests were accepted.

So I decided to fork LTBL2 in order to improve it.
This message is for any developer who wants to help the project to grow a little bit faster:
https://github.com/JumpingToasts/LTBL2

My main concerns are:

• Speed. I'm starting to improve the overall performance even if it requires to change the library interface. My aims are better data locality and as much as precomputing we can so that the render() loop can be the lightest of all. I think this is critical for games to run smoothly.
• Abilities. I'm really interested about what can LTBL offer to the user. Today, I added a feature to handle normal maps. An example can be found in the example folder.
• Interface. I was not really a big fan of original LTBL2 interface, as shared pointers add some computing penalty and no (easy) precise control of memory. I'm fully open to suggestions in order to improve the user experience.

I'll be glad to receive suggestions or (even better) pull requests via the repository issue system.

Please note that this version is in active development, and really not ready for use.
Thank you for reading.

Really happy to hear (see) this.

I use LTBL/LTBL2 on my projects. If i can contribute in something let me know.

[Jabberwocky]

Cool stuff, Breush!
I'd be interested to hear about any ongoing work you do, and really appreciate you sharing.

[Breush]

Cool stuff, Breush!
I'd be interested to hear about any ongoing work you do, and really appreciate you sharing.

Thanks Jabberwocky and DarkRoku.

Here's a quick sum-up of my thoughts:

• A small thing I'm doing is getting rid of std::shared_ptr<> in the interface, as the shared pointer is not stored internally in the library, I really don't get why there is this restriction. Doing so, I'm using offering a way to let LTBL manage the lights memory for the user, using some pre-allocated memory pool.
• I added a way to have the light react to normals, but one can imagine more (specularity/depth maps). And I've been doing so just for point lights, it needs to be extended to directional lights.
• I am not an expert in that domain, but I was wondering if I could compute some parts of the code in parallel.

Finally, for people who want to help but don't want to get their hands too dirty (@DarkRoku), I guess one thing you can do is to create a tricky example and try if things goes wrong. And if so, report an issue (and try debug it yourself if you can).
I also wanted to add a small SFML sandbox application to make test things quickly. (For instance, a right click creates a box you can resize, a left click creates a light, and you can drag'n drop things around.) But, I don't think I will do it right now, but I'll be glad to see someone doing that for the project.

But I don't have so much time right now, so it has been basic changes so far.
(I'll soon launch a Greenlight trailer for the game I'm developing, hopefully LTBL will make it shine! )
Afterwards, I will surely add a clear TODO list.

[DarkRoku12]

people who want to help but don't want to get their hands too dirty (@DarkRoku)

I´m re-mastering my game engine, and i had implement LTBL1 and LTBL2 (yes both), i will hard test your implementation.

I´m very insterested on the speed and interface part.

Hope you get all the success.

[Jabberwocky]

A small thing I'm doing is getting rid of std::shared_ptr<> in the interface, as the shared pointer is not stored internally in the library, I really don't get why there is this restriction. Doing so, I'm using offering a way to let LTBL manage the lights memory for the user, using some pre-allocated memory pool.

I got rid of the shared_pointers in the interface, too.

I added a way to have the light react to normals, but one can imagine more (specularity/depth maps). And I've been doing so just for point lights, it needs to be extended to directional lights.

This is an interesting one.  I've been considering doing the same thing.

Since LTBL just spits out a texture you overlay onto the scene, I'd be interested how you accomplished this.  Do you output a second texture of light direction, which can be used in a shader to combine with the normals?  The only problem there is that you couldn't combine these textures in the same way LTBL combines its light textures into a composite overlay texture.

I am not an expert in that domain, but I was wondering if I could compute some parts of the code in parallel.

Neither am I.  Although it does seem like the kind of code which could be run in parallel.

There's no doubt LTBL has a significant impact on performance.  Although I haven't measured whether that performance is primarily CPU or GPU (in which case running the code in parallel wouldn't matter). 

I'll soon launch a Greenlight trailer for the game I'm developing, hopefully LTBL will make it shine!

Awesome, and good luck!  Make sure you post a link here so we can upvote.

[Breush]

I added a way to have the light react to normals, but one can imagine more (specularity/depth maps). And I've been doing so just for point lights, it needs to be extended to directional lights.

This is an interesting one.  I've been considering doing the same thing.

Since LTBL just spits out a texture you overlay onto the scene, I'd be interested how you accomplished this.  Do you output a second texture of light direction, which can be used in a shader to combine with the normals?  The only problem there is that you couldn't combine these textures in the same way LTBL combines its light textures into a composite overlay texture.

There is a dedicated example in the repository.
I do have a separate RenderTexture for the normals.
The idea is that each time you draw something,you also draw the normals version of it to the normals texture:

        head.setTexture(headTexture);
        window.draw(head);
        head.setTexture(headNormalsTexture);
        ls.normalsTargetDraw(head);

That way, whatever your scene graph is, you'll get a full representation of your scene in normals.
I think this is flexible enough to adapt to each system.

Afterwards, when the light system renders its lights, it will use the full normals texture for each composite part.
And you get the usual LTBL light texture to add to your scene (but with normals matching your scene!).

[Jabberwocky]

There is a dedicated example in the repository.
I do have a separate RenderTexture for the normals.
The idea is that each time you draw something,you also draw the normals version of it to the normals texture:

        head.setTexture(headTexture);
        window.draw(head);
        head.setTexture(headNormalsTexture);
        ls.normalsTargetDraw(head);

That way, whatever your scene graph is, you'll get a full representation of your scene in normals.
I think this is flexible enough to adapt to each system.

Afterwards, when the light system renders its lights, it will use the full normals texture for each composite part.
And you get the usual LTBL light texture to add to your scene (but with normals matching your scene!).

Ahh, right, that totally makes sense.

I was thinking about it in the wrong way (storing the light direction in a texture, not the scene normals).  It kind of works like a 3D deferred rendering pipeline.

Cool!

[R23MJ]

If anything, I just want to be able to build this for windows; last time I checked it didn't work well and my only option was to add the files to my project. Which got clustered quickly. Anywho, I guess it's cool someone picked up the project.

[DJuego]

A lot of cheers and luck with your initiative, Breush!

I also am very interested in a ultimate 2D lighting system! 

DJuego

[Breush]

If anything, I just want to be able to build this for windows; last time I checked it didn't work well and my only option was to add the files to my project. Which got clustered quickly. Anywho, I guess it's cool someone picked up the project.

I checked on Windows with MinGW32 and it did not worked. But I just fixed it.
The fact is that the compiler was confused because of the name Math.h, which it believed to be the standard include <math.h>. Strange but hey...
I don't have Visual Studio to test, but I know you'd need a recent version in order to have decent C++11 features.

[DarkRoku12]

If anything, I just want to be able to build this for windows; last time I checked it didn't work well and my only option was to add the files to my project. Which got clustered quickly. Anywho, I guess it's cool someone picked up the project.

I checked on Windows with MinGW32 and it did not worked. But I just fixed it.
The fact is that the compiler was confused because of the name Math.h, which it believed to be the standard include <math.h>. Strange but hey...
I don't have Visual Studio to test, but I know you'd need a recent version in order to have decent C++11 features.

I can test it on Visual Studio 2013.

Want to i tried it know or better wait some days?

[DJuego]

If you allow me, I will partner with you in this beautiful purpose.

I can test it on Visual Studio 2015 when Breush considers the moment has come.

DJuego

[Breush]

I can test it on Visual Studio 2013.
Want to i tried it know or better wait some days?

If you allow me, I will partner with you in this beautiful purpose.
I can test it on Visual Studio 2015 when Breush considers the moment has come.

Well, even if the project is not ready for release, I think the sooner, the better.
Because if there are some things I have to be careful about when coding, I'd like to know right now.

The repository has a CMake. It should be easy for you guys to test.
Let me know via an issue on GitHub or a pull request if you can fix it.

Thanks.