Dynamic lighting on Sprites with Sprite DLight
Deee
Member Posts: 7
Hi everyone,
I would like to introduce the tool for 2D game developers I am currently working on.
Sprite DLight is a tool that generates instant normal maps from 2D sprites in one click.
This way, you could create a game featuring dynamic lighting on pixel art characters and objects, simply by processing the existing game art and using the normal maps in combination with a shader.
The pretty successful Kickstarter campaign for the tool will end in 6 days, all stretch goals are already reached.
Real dynamic lighting might not be possible for all platforms GameSalad supports, but Sprite DLight is also capable of re-rendering sprites for different environments, based on the generated normal map.
With this feature, the color and intensity of four ambient lights can be adjusted to fit the lighting conditions of the game environment, where the spot light is reduced to its directional component, which allows for consistent lighting for multiple frames of a sprite sheet.
"Super Aged Warriors Alpha 2 HD Turbo Special", ©2014 AlbertoV (DYA Games), re-rendered for different environments with the normal map and lighting of Sprite DLight
There will also be an animation preview for sprite sheets, so you can see how they turn out with dynamic lighting.
"Selen Run Animation", ©2014 Lunar Ray Games, animated dynamic lighting preview of the sprite sheet in Sprite DLight
This is a screenshot of the tool. The UI is currently being redesigned.
Sprite DLight's Kickstarter campaign will end next Friday at 4:00 PM CST, there are 5 days left to jump in for the beta and to pre-order the tool at the Kickstarter backer price.
Sprite DLight is also on Steam Greenlight, hoping for more Yes votes.
I appreciate any kind of feedback and ideas for the integration with GameSalad.
Comments
Speak to the Gs peeps man if this could be intergrated with the tool and so when you import an animation image you can set the light direction and it can edit your image to the ones here , that would be so awesome !!!±!!!!!::DD:D:DD::D
You can do it now ! You just need to constrain the image used to the vector to angle between the actor and the light source.
This looks cool! Looking forward to this when its released.
Nice one @Socks!
Twitter:rondorocket
Web: rondorocket.com
Did a quick test, it's pretty crude as I only resolved the light into 72 positions (5°), you could of course make it much smoother, the actual implementation is easy, trivial even, it consists of a single constrain behaviour which constrains the image to the angle between the actor and the light source.
@Deee
@RondoRocket
Also multiple objects with a single light source is pretty straightforward too . . .
Socks, this looks amazing!
Could you show the normal map you used in this example?
And is is possible to use multiple light sources?
I didn't use a normal map, I used actual geometry for the test (obviously with your thing you can use flat illustrations). . . I was trying to work out how you could implement your bump/normal map inside GameSalad as all GameSalad can really do is import images.
One thing GameSalad is great at is throwing lots of images around.
So, you would generate a normal / bump map from the original image, then render the image with the bump map applied from a number of angles (as many or as few as you need / want / like) . . . you import these images into GameSalad (their name reflecting the angle of the light used to render them, so AxeMan_10, Axeman_20, AxeMan_30 etc), make an actor (the 'main' actor), then make a light actor and constrain the main actor's image to the angle between the two.
So if the angle between the two is 20°, then the main actor will use AxeMan_20.
Well, you could separate the light from the image, to instead of rendering the image with the bump map applied (and lit), you'd render just the bump map lit (essentially a black image, but with the bump map applied so you catch some specular light) - then import this 'light' sequence (again as many images / degrees° as you need) - and constrain it to the main actor (which has the unlit original image applied to it) - make sure the 'light' actor is set to add / screen - then give the 'light' actor the same rule as above governing which image it uses. Now this set up will function the same as the version above, an actor that reacts to the position of the light, but you can add as many additional light actors as you want - you would of course have to adjust each layer to suit - and each layer can have its own colour light (simply by changing the actors colour) - and you can also throw a magnitude function onto each light actor, controlling its alpha channel, so that as the light moves to a more distant position the light strength falls off.
Wow ! Just seen your KickStarter, 6x times the target funding already, impressive stuff
Just did a super quick 2 light version, I just used the image I already had, didn't bother rendering the light separately (which you would have to do), and the distance falloff is switched off (whoops!
) so it's really really crude, but it gives you a basic idea . . .
Your examples look super awesome, Socks!
However, I think it would be way too much of a hassle to go this route for a full game.
Even though batch processing allows the rendering for different angles pretty quickly, imagine the chaos you would end up with when having 36 images for each and every frame of an animated character...
Great job, though!
So impressive, @Socks; excellent stuff.
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
I would love actual normal mapping to be integrated into GS. Sprite DLight looks great, gonna keep it in mind for future projects not tied to GS.
Follow us: Twitter - Website
Amazing stuff @Socks, love seeing examples like this! Looking forward to when you unleash your stuff on the Marketplace.
Also looking forward to when @Deee releases Sprite DLight!
Twitter:rondorocket
Web: rondorocket.com
In theory there wouldn't be any hassle at all as it would mostly be automated.
I can't imagine the chaos, there is no chaos as far as I'm aware !?
I do this kind of thing all the time, it normally consists of little more than 1 or 2 one line rules, it's not even complicated let alone chaotic ! I'm not sure how you are using 'chaos' in this context (do you simply mean lots of images?) - in your running girl example above, you have 10 frames, with 36 lighting angles that would be 360 images, which is no big deal to be honest, I do projects all the time with hundreds of images (recently did a test with 10,000 images [0-9,999]) and GameSalad didn't complain in the least, it ran at 60fps on an old iPad2, and like I say you don't actually have to do anything with the images other than import them as it would all be automated on the generation side - and then driven by a constrain behaviour on the GameSalad side.
Besides pre-rendering I can't see how you would be able to implement your system into GameSalad, although maybe it's worth shooting @CodeWizard a message, maybe there's another way to get this working with GameSalad in the future ? Whichever way it's done it looks like a really nice effect.
Something crossed my mind while thinking about lighting in GS. The image method @Socks posted is pretty cool and got me thinking, If we can manipulate RGBA values in GS, then with some careful planning you can create an illusion of lighting.
For example if you have a light actor (or multiple) and an actor wanting to be lit you can make the illusion of lighting by removing the red's intensity the farther it gets from the light source.
So you constrain an actor who needs lightings red value to ((((magnitude( self.Position.X - game.XLight , self.Position.Y - game.YLight ))*-1)/255)+game.Lightintensity)
And now the red value gets restored the closer you get to the "light". This look especially nice if you use a image of the light actor that actually looks like a light, or use a blend mode in addition to this method.
Follow us: Twitter - Website
Yes!
I mention this in my post above . . .
"and you can also throw a magnitude function onto each light actor, controlling its alpha channel, so that as the light moves to a more distant position the light strength falls off"
I also did a more involved test of this idea in the experiment video below (you can read about it on page 5 of this thread: http://forums.gamesalad.com/discussion/70318/experiment/p5 )
Sweet, that's really cool looking!
Created a nice little demo for myself now with seperate r, g, b lights and some min,max thrown into the mix for greater control. Also considering testing out a "spec map " constrained to an actor that reacts to the lights instead of the actor itself, pure white specular would be when rgba channels max out.
Follow us: Twitter - Website
Sound good !
Lighting effects look great in games, you should upload a video of your tests.
Sounds good too, would you create the specular image separately, in a 3D software for example ?
If you have time could you post a download link for the light demonstration? Im having a hard time understanding this thread lol
Wow, @Socks - that truly deserves an "Awesome".
(*) 
And an Awesome for @Deee - best of luck with your Kickstarter campaign.
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
Very nice work!
@Socks, I just thought it could lead to performance issues and require a lot of disk space, if there are 10 additional images for every single sprite of a whole game (particularly when thinking of larger sprites).
Sprite DLight's Kickstarter is over now, and I am currently focusing on the first beta build.
However, I will be checking back here regularly, and I have listed this thread in the engine integration link collection here.
@Deee Sprite DLight looks incredibly useful - especially with animated sprites! That uniform lighting on all the frames delivers a beautiful visual effect. I just pledged Pro on your site
Can't wait to play around with the beta.
@Socks Nice demo videos! I would've thought having individual images for every angle of bump map for every single frame of every sprite in a game would be disastrous but it seems you're correct that GameSalad excels at throwing around many images.
@AlchimiaStudios I love your 'illusion of lighting' method by removing color intensity using ((((magnitude( self.Position.X - game.XLight , self.Position.Y - game.YLight ))*-1)/255)+game.Lightintensity)
Yep, I've never understood the hesitation when it comes to using lots of images in GameSalad, lots of people say it will be chaotic, crazy, unstable, disastrous, your teeth will fall out and your cat will leave home
. . . but no one ever manages to give a reason why this should be the case, I regularly use image sequences in the hundreds of frames, if they're not large images then there are no issues with memory (for example one thousand 200 x 64 pixel images comes to 3MB), if they are part of an animated sequence then you will only be displaying 1 image at any given time, so a 500 frame loop is no more strain on a mobile device's processor than a 5 frame loop . . . but you still hear people say things like _"that would mean I'd need 16 separate images for the alien ! No way !" 
@socks that's one pretty great lighting demo rite there well done sir! Going to have to try this at the weekend!