I have absolutely no reason to ever use this but I'm absolutely going to throw money at the author because I'm a sucker for pixel art and this looks incredible. (I spent like five minutes staring at the zombie .gif, slackjawed.)
My girlfriend (who is responsible for most of the art in the examples) and I pretty much reacted the same way when we first got the algorithm working. It was one of those things that went from 'not working at all' to 'suddenly working perfectly when you fix one broken thing'. Good times.
I was impressed when I saw this story yesterday and really liked the idea behind Sprite Lamp, so I figured out the algorithm and wrote a program that replicates its basic functionality of generating normal maps for 2D sprites lit from four directions: http://i.imgur.com/H1H0R8k.png. The program will need some more work before it can be practically used but it's the same basic idea.
I intend to release it as a command line tool under a free license; I do not intend to compete with Sprite Lamp by building an artist-friendly GUI or implementing lots of fine-tuning. The idea has been used in games before and seemingly isn't patented but Snake Hill Games are, as far I can tell, the first to offer this functionality in a stand-alone tool. I would like to see them succeed but I also feel that having a FOSS implementation of this algorithm (mine or otherwise) would be a benefit to the community.
Should I wait until the end of the Kickstarter campaign (edit: or longer) to release it?
This algorithm has been written a thousand times, and probably already exists somewhere online, hidden deep within the internet.
And as you say, it targets a completely different set of users. Sprite Lamp, is building something for artists to use, while the people who want a command line tool, would likely try to build it themselves rather than try to fit the .NET gui into their pipeline.
And additionally, it's likely that your release won't spread fast in the same channels at all, not really even showing up on the radar of many potential contributors of Sprite Lamp.
My point is, the ethics of the decision really only matter if you are going to have any affect on the kickstarter campaign. (Which I think even then you'd be in the proper right to release your code) But your unlikely to affect the kickstarter at all. So, IMO, I think you should release now, and ride the wave a little bit for people who like the idea of Sprite Lamp, but don't like the idea of the interface.
Update: I've emailed the developer of Sprite Lamp. Depending on his response I will release my implementation of the normal map generator to the public either as soon as it's ready (which might take a few days) or after the end of his Kickstarter campaign.
At least one HN user has shown interest in this tool, so as a compromise in case Snake Hill Games does ask me to wait until the end of the Kickstarter campaign I've set up a Google Group [1] for those who might want to test it before the public release. Depending on the circumstances I'll post a private download link or a GitHub link in the group once it's ready.
I'd personally prefer a simple CLI for the tool over a GUI, so I'd certainly be interested. Anyway, as long as you're not doing a competing KS or something, I can't see any fundamental ethical problems with releasing it. The sprite lamp idea itself is not that original, although the presentation is very neat. In fact, I'll probably support it in any case, because it brought the idea up.
Open source it. You independently did all the work, you're not making any money from it, and you're not using any of his trademarks. There is no "business" here.
If sprite lamp is successful someone will write a FOSS version of it anyway. Commercializing a product takes a lot more than writing a commandline version of the algorithm.
I'd say release it. There is nothing wrong with competition, capitalism works because of it. Sprite Lamp will have to provide a better product if they want to earn money from it.
Better to be confronted with a FOSS version now than when they have invested a lot of time and money into their own product.
It'd be unethical to try and piggy-back on Sprite Lamp's popularity to advance your project. For example, submitting your project later on to HN under the "my take on spite lamp" title.
This is a very cool technique. I have been thinking about how to generate normal maps for traditionally drawn 2D images ever since seeing the normal mapped canvas demo[1]. This seems to be an answer.
Drawing lighting profiles that are coherent however does not seem simple. One of the uses of this technique "Depth maps for stereoscopic 3D" appears much more complicated to me that drawing a depth map by hand in the first place. I drew a depth map for my drawing Starry Venice[2] as a step in making it into a wigglegif. Drawing multiple correct light profiles to generate the depth map for a scene such as Starry Venice seems almost impossible to me. This is far from the base use-case, but still.
It will be interesting to see how forgiving the creation of the normal map will be on imperfect light profile inputs. Also, it will be interesting to see if any artists who are masters of this technique will emerge.
Thanks! And, that javascript canvas demo is relevant to my interest - thanks for the link!
You're right in your suspicion that depth map generation in Sprite Lamp is not a silver bullet for stuff like that. Images with big discontinuities in depth (especially open scenes, like the one you linked) will likely get you some pretty dubious results in Sprite Lamp. On the other hand, if you look closely at the self-shadowing on the brick gif from the website, I think you'll agree that the results are pretty accurate (note that the little notches and scrapes in the surface of some bricks get picked up accurately too) - while you could paint that map by hand, I suspect that getting the results that nice would take some time, and Sprite Lamp does it in a second or two (pre-optimisation). Stuff like character artwork (like the zombie or the plague doctor) fall somewhere in between - you get results that are good enough for self-shadowing, and with some tweaking you can generate a nice stereogram, but it's not necessarily 'physically accurate' (which in this case is another way of saying "I can't guarantee the results are what the artist pictured").
I'm reluctant to promise features that I haven't tried yet, but I'm planning on some experimentation with a combination of painting depth values and using Sprite Lamp - this will take the form of some tools for messing with the depth map from within Sprite Lamp after it's been generated, with an eye to intelligently detecting potential edges and letting you move whole bits of the scene around at once (and then an integrated means of actually looking at the depth map you've created - wigglegifs might be a good option there, actually).
As an artist myself, I actually think making these assets would be quite easy. I already use layers in Photoshop to first draw my "diffuse map" image, then draw the shading as layers on top of it. It would essentially be the same exact process I already go through to draw cartoons, just with the added steps of drawing a couple more shading layers.
For line art (like the zombie example) it may be possible to use one of several available semi-automated algorithms to generate a depth map. Here's a page that shows a few:
Whoa cool. This will work well. I implemented a similar dynamic lighting solution for sprites back in 1997. I used 3D models though that were rendered and then the pure colors and Z-buffer were captured for dynamic lighting effects. Mentioned here as "Software Prototype: Real-time 2D Sprite Shader":
Very cool. I think some MMOs are using that technique in conjunction with server-side rendering for displaying good quality distant objects without having to push as much geometry to the client. Also nice work on Clara, I'm particularly looking forward to V-Ray support.
Super cool! Confederate Express[1] is using a similar workflow, with great results. It's a really cool idea, and I'm surprised that it hasn't been used in more games up to this point. Seeing projects like this -- and spriter[2] and spine[3], really does make me want to get back into game development.
Holy moly. I'm the guy that's working on Sprite Lamp, and I just woke up to this thread (and a giant spike in my web traffic). Thanks everyone for the enthusiasm and support! I guess I don't have anything general to say - there are probably too many words on the website as it is - but I'll do my best to answer people's questions here.
Don't you have to be incredibly skilled to draw lighting from different directions? I'm thinking "yes" - but artists are incredibly skilled.
The free version will do everything the hobbyist version can do, but without the
ability to export assets [...] needed for game use – however, the user will be able
to export (watermarked) animated gifs showing off their artwork.
Great pricing scheme! I hope it works because I'd like to use this scheme too.
As a (somewhat rusty) pixel artist I'd say it is easier to draw lighting from, say, straight above, or from the right, than from some arbitrary angle. But it still takes practice and a good eye, certainly.
This technique is fairly common in 2d games now. I wrote a blog post on this technique along with a form of ray tracing to also cast shadows in a 2d game: http://mattgreer.org/post/4dynamicLightingShadows
This is very impressive, very nice post. However I don't really understand the idea of using Kickstarter to build a paid product. If the community pay for it, then it should be free software. I don't mind it being proprietary, but then I don't see why people would put money to kickstart it. Especially since it seems to be working already.
But I can't help feeling that generating normal maps from full 3D models would be more robust overall.
For instance you could easily make things like a walking animation or calculate ambient occlusion (pretty standard 3ds max work.) Render it into a sprite sheet and you have the pipeline to dramatically reduce the amount of work artists would have to do.
I guess Sprite Lamp would be best geared toward indies/studios without 3D modelers and can't invest in the aforementioned tech.
Almost all the interesting games being made nowadays are indie games, and as you say most indie game makers don't have the budget for 3D modelers. Not all of them necessarily want this effect, but I'd still say that this could have a pretty big impact.
Drawing lighting profiles seems much simpler than drawing normal maps, and more flexible than drawing height-maps. I had access to the Sprite Lamp alpha, and was able to come up with these images [1][2] in a short amount of time. I am enthusiastic about the future of pixel art games that use sprites that have more information encoded in them (lighting, material, physics).
Completely off-topic, so first off: Sprite Lamp looks really awesome, great job and fingers crossed for a successful Kickstarter!
But, does anybody else use "upvotes vs # of comments" as a useful metric around here? I'm not actually running a tally but I believe this story takes the cake, at least over the last few weeks (months?) with currently 750 upvotes vs only 70 comments.
In short, I find the number of upvotes divided by the number of comments (or perhaps minus the number of comments) a better metric to determine the "interestingness" of a story compared to the number of upvotes alone. It's not a hard-and-fast rule, but I've noticed myself paying more attention to this dividend/sum recently than to the points alone.
I've pondered the thought a little bit over the past few months and of course there are several factors at play here, so there's not one single explanation for the phenomenon. But here is one shot:
When somebody comments on a story, there's an incentive to also upvote it because of the karma system: the more upvotes a story gets that you've commented on, the higher the likelihood that your comment gets upvoted. Perhaps not everybody thinks like that, but I think it's fair to say that a good percentage of commenters might upvote a story for their comment's sake and not necessarily for the story's sake. (Of course that's simplifying things: when you comment on a story, you probably also find the story interesting so you might have upvoted it anyway, karma or not.)
Anyway, from that perspective, the difference between number of upvotes and number of comments could be termed "genuine upvotes": people who really just thought it was a cool story, without any second thoughts regarding their karma balance and without necessarily having a strong opinion on the subject matter.
There are of course other, and perhaps simpler, factors/explanations: the less comments a story gets, the less controversial it is so if a story gets many upvotes and few comments, then perhaps it simply is uncontroversially good.
I've played with the idea of writing an alternate HN interface that uses this metric to weigh stories, but it never got anywhere. And there certainly isn't a simple solution: how to combine age, upvotes and number of comments into a useful ranking is black magic at best.
Again sorry for this offtopic blurb. It's just something I found myself thinking about a bit, and this story seems like a particularly good example.
And now back to 3d-inspired 2d awesomeness. How come I've never thought of this!
I find the opposite case: I prefer articles that have a parity between upvotes and comments. To me, an upvote is a drive-by action, where a comment indicates real engagement. If an article has tons of upvotes, but not many comments, it means most people aren't really paying close attention to it, they're just thumbs-upping geek cred or something.
I am not an expert on 2d art or dynamic lightning, but I recognize that this technology is potentially really awesome. So I would upvote this story as something I find really interesting, but I would withhold on commenting as I have nothing specific to add to the discussion.
It would be interesting if a website like hackernews hides the number of upvotes and then see how people will vote. I'm suspecting some kind of herd mentality when it comes to upvotes in general to be honest.
So all the examples only use one light... how many lights can you have in a scene? What kinds of lights are supported (omni, spot, etc)? Can you use different colors of lights? If I wanted to use hundreds of lit particles in a scene, how performant would it be?
It seems like the main use case is exporting the normal/depth/ambient occlusion maps, which you'd probably end up dropping into your engine of choice rather than using Sprite Lamp itself in your game (Sprite Lamp would generate the assets, but the game engine would display them).
If you have the maps, there's no hard limit to the number of lights you can have in your scene, or colors, etc; it just depends how many lights your engine can support with decent performance.
Think of Sprite Lamp more like Blender than like Unity — Sprite Lamp is a way to create assets.
I'm no graphics guy (not even by a long shot), but my understanding of this is that it's generating the same maps that you'd otherwise have to generate through some other process. The images used to generate them have a single point source, but I have to assume that, once generated, the maps would work just as well for multiple or different types of light sources. As for performance, that's entirely up to whatever engine you're using to render the damn thing; once you have the maps, you're done with SpriteKit.
As far as lighting goes, I think it would be as performant as it gets. It's the same idea as deferred shading; you only have to shade the pixels that the light affects.
As for types of lights and colors, yes, I think that would all be possible.
Which part? For the main lighting technique, most of the magic comes from the artist providing the surface normal components. Then to produce the image under some specified lighting direction, you can do the normal 3D graphics thing: dot product the light vector with the normal vector and scale that by the diffuse color.
http://en.wikipedia.org/wiki/Lambertian_reflectance
In case the artist doesn't draw the X,Y, and Z surface normal components directly but instead chooses some other set of lighting profiles, you could use photometric stereo to recover the surface normals. (If this is the approach used, then applying such a technique to specially-crafted pixel art is indeed novel).
My guess is that it works by blending the hard-light-case sprites trigonometrically, w.r.t. the vector between the position of the light and the origin/sprite.
[+] [-] jmduke|12 years ago|reply
[+] [-] Dinaroozie|12 years ago|reply
Oh and thanks for the offer of thrown money!
[+] [-] hfsktr|12 years ago|reply
[+] [-] networked|12 years ago|reply
I was impressed when I saw this story yesterday and really liked the idea behind Sprite Lamp, so I figured out the algorithm and wrote a program that replicates its basic functionality of generating normal maps for 2D sprites lit from four directions: http://i.imgur.com/H1H0R8k.png. The program will need some more work before it can be practically used but it's the same basic idea.
I intend to release it as a command line tool under a free license; I do not intend to compete with Sprite Lamp by building an artist-friendly GUI or implementing lots of fine-tuning. The idea has been used in games before and seemingly isn't patented but Snake Hill Games are, as far I can tell, the first to offer this functionality in a stand-alone tool. I would like to see them succeed but I also feel that having a FOSS implementation of this algorithm (mine or otherwise) would be a benefit to the community.
Should I wait until the end of the Kickstarter campaign (edit: or longer) to release it?
[+] [-] Arelius|12 years ago|reply
And as you say, it targets a completely different set of users. Sprite Lamp, is building something for artists to use, while the people who want a command line tool, would likely try to build it themselves rather than try to fit the .NET gui into their pipeline.
And additionally, it's likely that your release won't spread fast in the same channels at all, not really even showing up on the radar of many potential contributors of Sprite Lamp.
My point is, the ethics of the decision really only matter if you are going to have any affect on the kickstarter campaign. (Which I think even then you'd be in the proper right to release your code) But your unlikely to affect the kickstarter at all. So, IMO, I think you should release now, and ride the wave a little bit for people who like the idea of Sprite Lamp, but don't like the idea of the interface.
[+] [-] networked|12 years ago|reply
At least one HN user has shown interest in this tool, so as a compromise in case Snake Hill Games does ask me to wait until the end of the Kickstarter campaign I've set up a Google Group [1] for those who might want to test it before the public release. Depending on the circumstances I'll post a private download link or a GitHub link in the group once it's ready.
[1] https://groups.google.com/forum/#!forum/unflatterer
[+] [-] nurbl|12 years ago|reply
[+] [-] AndyKelley|12 years ago|reply
[+] [-] BetaCygni|12 years ago|reply
I'd say release it. There is nothing wrong with competition, capitalism works because of it. Sprite Lamp will have to provide a better product if they want to earn money from it.
Better to be confronted with a FOSS version now than when they have invested a lot of time and money into their own product.
[+] [-] eps|12 years ago|reply
[+] [-] aleyan|12 years ago|reply
This is a very cool technique. I have been thinking about how to generate normal maps for traditionally drawn 2D images ever since seeing the normal mapped canvas demo[1]. This seems to be an answer.
Drawing lighting profiles that are coherent however does not seem simple. One of the uses of this technique "Depth maps for stereoscopic 3D" appears much more complicated to me that drawing a depth map by hand in the first place. I drew a depth map for my drawing Starry Venice[2] as a step in making it into a wigglegif. Drawing multiple correct light profiles to generate the depth map for a scene such as Starry Venice seems almost impossible to me. This is far from the base use-case, but still.
It will be interesting to see how forgiving the creation of the normal map will be on imperfect light profile inputs. Also, it will be interesting to see if any artists who are masters of this technique will emerge.
[1] http://29a.ch/2010/3/24/normal-mapping-with-javascript-and-c... [2] http://fooladder.tumblr.com/post/61216111704/starry-venice
[+] [-] Dinaroozie|12 years ago|reply
You're right in your suspicion that depth map generation in Sprite Lamp is not a silver bullet for stuff like that. Images with big discontinuities in depth (especially open scenes, like the one you linked) will likely get you some pretty dubious results in Sprite Lamp. On the other hand, if you look closely at the self-shadowing on the brick gif from the website, I think you'll agree that the results are pretty accurate (note that the little notches and scrapes in the surface of some bricks get picked up accurately too) - while you could paint that map by hand, I suspect that getting the results that nice would take some time, and Sprite Lamp does it in a second or two (pre-optimisation). Stuff like character artwork (like the zombie or the plague doctor) fall somewhere in between - you get results that are good enough for self-shadowing, and with some tweaking you can generate a nice stereogram, but it's not necessarily 'physically accurate' (which in this case is another way of saying "I can't guarantee the results are what the artist pictured").
I'm reluctant to promise features that I haven't tried yet, but I'm planning on some experimentation with a combination of painting depth values and using Sprite Lamp - this will take the form of some tools for messing with the depth map from within Sprite Lamp after it's been generated, with an eye to intelligently detecting potential edges and letting you move whole bits of the scene around at once (and then an integrated means of actually looking at the depth map you've created - wigglegifs might be a good option there, actually).
[+] [-] moron4hire|12 years ago|reply
[+] [-] jcl|12 years ago|reply
http://parter.kaist.ac.kr/jyhahn76/project13.html
[+] [-] bhouston|12 years ago|reply
http://www.exocortex.org/ben/#High_School-Era_and_Earlier_Pr...
[+] [-] hedgehog|12 years ago|reply
[+] [-] 32bitkid|12 years ago|reply
[1]: http://www.kickstarter.com/projects/829559023/confederate-ex...
[2]: http://www.brashmonkey.com/spriter.htm
[3]: http://esotericsoftware.com/
[+] [-] errnoh|12 years ago|reply
Kudos to both, dynamic lighting on 2D art looks great.
[+] [-] Dinaroozie|12 years ago|reply
[+] [-] SteroidsLove|12 years ago|reply
[+] [-] 6ren|12 years ago|reply
[+] [-] sillysaurus2|12 years ago|reply
Artists have to do that anyway. :) This way, after they draw a few angles, software can automate the rest.
[+] [-] nurbl|12 years ago|reply
[+] [-] city41|12 years ago|reply
[+] [-] adamwong246|12 years ago|reply
This game totally needs to implement this. It has some similar ideas though. Take a look at this closely: https://s3.amazonaws.com/ksr/assets/000/945/686/c415709a876b...
notice how the wind blowing right to left affects the sprite: his cloak moves with the wind. Now that's attention to detail!
[+] [-] tsaoutourpants|12 years ago|reply
[+] [-] p4bl0|12 years ago|reply
[+] [-] mrhyperpenguin|12 years ago|reply
But I can't help feeling that generating normal maps from full 3D models would be more robust overall.
For instance you could easily make things like a walking animation or calculate ambient occlusion (pretty standard 3ds max work.) Render it into a sprite sheet and you have the pipeline to dramatically reduce the amount of work artists would have to do.
I guess Sprite Lamp would be best geared toward indies/studios without 3D modelers and can't invest in the aforementioned tech.
This is cool nonetheless.
[+] [-] ecuzzillo|12 years ago|reply
[+] [-] eigenbom|12 years ago|reply
1. http://bp.io/wp/wp-content/uploads/2013/11/hospital2.gif 2. http://bp.io/wp/wp-content/uploads/2013/11/img_Preview.gif
[+] [-] winslow|12 years ago|reply
[+] [-] colanderman|12 years ago|reply
[+] [-] julian37|12 years ago|reply
But, does anybody else use "upvotes vs # of comments" as a useful metric around here? I'm not actually running a tally but I believe this story takes the cake, at least over the last few weeks (months?) with currently 750 upvotes vs only 70 comments.
In short, I find the number of upvotes divided by the number of comments (or perhaps minus the number of comments) a better metric to determine the "interestingness" of a story compared to the number of upvotes alone. It's not a hard-and-fast rule, but I've noticed myself paying more attention to this dividend/sum recently than to the points alone.
I've pondered the thought a little bit over the past few months and of course there are several factors at play here, so there's not one single explanation for the phenomenon. But here is one shot:
When somebody comments on a story, there's an incentive to also upvote it because of the karma system: the more upvotes a story gets that you've commented on, the higher the likelihood that your comment gets upvoted. Perhaps not everybody thinks like that, but I think it's fair to say that a good percentage of commenters might upvote a story for their comment's sake and not necessarily for the story's sake. (Of course that's simplifying things: when you comment on a story, you probably also find the story interesting so you might have upvoted it anyway, karma or not.)
Anyway, from that perspective, the difference between number of upvotes and number of comments could be termed "genuine upvotes": people who really just thought it was a cool story, without any second thoughts regarding their karma balance and without necessarily having a strong opinion on the subject matter.
There are of course other, and perhaps simpler, factors/explanations: the less comments a story gets, the less controversial it is so if a story gets many upvotes and few comments, then perhaps it simply is uncontroversially good.
I've played with the idea of writing an alternate HN interface that uses this metric to weigh stories, but it never got anywhere. And there certainly isn't a simple solution: how to combine age, upvotes and number of comments into a useful ranking is black magic at best.
Again sorry for this offtopic blurb. It's just something I found myself thinking about a bit, and this story seems like a particularly good example.
And now back to 3d-inspired 2d awesomeness. How come I've never thought of this!
[+] [-] moron4hire|12 years ago|reply
[+] [-] diziet|12 years ago|reply
[+] [-] jcl|12 years ago|reply
https://news.ycombinator.com/item?id=2386658
[+] [-] ilovecookies|12 years ago|reply
[+] [-] jamesaguilar|12 years ago|reply
[+] [-] Fauntleroy|12 years ago|reply
[+] [-] reissbaker|12 years ago|reply
If you have the maps, there's no hard limit to the number of lights you can have in your scene, or colors, etc; it just depends how many lights your engine can support with decent performance.
Think of Sprite Lamp more like Blender than like Unity — Sprite Lamp is a way to create assets.
[+] [-] eridius|12 years ago|reply
[+] [-] mrhyperpenguin|12 years ago|reply
As for types of lights and colors, yes, I think that would all be possible.
[+] [-] robobenjie|12 years ago|reply
[+] [-] ThomW|12 years ago|reply
http://robotloveskitty.tumblr.com/post/33164532086/legend-of...
Unity just put up a story about the game yesterday as well: http://unity3d.com/gallery/made-with-unity/profiles/legend-o...
[+] [-] joshvm|12 years ago|reply
[+] [-] GrantS|12 years ago|reply
In case the artist doesn't draw the X,Y, and Z surface normal components directly but instead chooses some other set of lighting profiles, you could use photometric stereo to recover the surface normals. (If this is the approach used, then applying such a technique to specially-crafted pixel art is indeed novel).
Here's a factorization technique for photometric stereo that could be applied to the artist inputs: http://www.wisdom.weizmann.ac.il/mathusers/vision/courses/20...
[+] [-] pizza|12 years ago|reply
[+] [-] rcfox|12 years ago|reply