Sprite Lamp
spritelamp.com
spritelamp.com
Oh and thanks for the offer of thrown money!
This tool looks amazing and this will be my first time supporting a project via kickstater!
And, thanks!
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?
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.
If Sprite Lamp can fit a similar niche to Texture Packer then it can be successful. For example, if it implements multiple normal-determination algorithms, has loads of parameters to tweak, accepts and outputs many different formats, and has a stable and great looking GUI.
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 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.
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
The artist should be doing this already!
I could see this getting prohibitive when creating animations for example.
BUT, with that 2x effort, you're getting a significant improvement in visual quality. The alternative would be the Donkey Kong Country option: model the character in 3D (easily 10x more effort than flat 2D animation, with a much more expensive work force and software), bake in the lighting, and generate gigantic animation sheets. Your asset library will explode in size. The games that have done this have tended to employ significant compression on the images, which can negatively impact visual quality.
And technically you could export the sprite sheet with however many frames you want (and be able to lower and increase the number easily) while still getting the exact same results as the Sprite Lamp solution. And of course artists could go in and manually make any changes they want.
It's interesting hearing the perspective of the artists. Thanks.
Also there are major stylistic advantages to drawing it by hand. Check out the baked-in motion blur on Sonic's feet in this sprite rip of Sonic 1: http://www.spriters-resource.com/genesis_32x_scd/sonicth1/sh... a while back there was a 2.5d Sonic game, and its motion had a lot less impact because no attempt was made to replicate the motion blur.
Plus of course if you're just drawing it you don't have to worry whether or not it actually makes sense - a lot of the more stylized cartoon characters are VERY hard to build spot-on 3d models of, because they're full of weird abstractions that only make sense in the 2d plane.
And finally, some people just don't like modeling stuff in 3d.
(I'm an artist and ex-animator.)
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).
http://www.exocortex.org/ben/#High_School-Era_and_Earlier_Pr...
[1]: http://www.kickstarter.com/projects/829559023/confederate-ex...
Kudos to both, dynamic lighting on 2D art looks great.
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.
Artists have to do that anyway. :) This way, after they draw a few angles, software can automate the rest.
For unusual lighting (e.g. uplit), even an excellent artist would have to give it more attention. Similar to drawing a character from an unusual perspective. At any rate, drawing several unusual lighting angles will exercise one's talents more than using the same standard one.
It's literally looking at it in a new light.
Why not have the artist enter height directly, instead of shading from several different angles? It seems like less work (because there's less information to input); though possibly doesn't mesh as well with how 2D artists work... whereas shading is part of the tradition.
There's something I'm not getting here (that might lead to a better way of doing it, or not).
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!
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.
You might even say it could be a game changer.
Personally, I would never try to do this kind of work by hand in 2D (not a talented-enough draftsman). But the grandparent is right...even in my clumsy hands, I can do a decent job working in 3D. It's just an easier workflow.
Now, style-wise, nice hand-drawn 2D animation is in a class of its own. If indie studios are sticking with 2D, I'd suggest it's frequently more a matter of style than price.
To create a rich 2D world, you probably can get by with one or two talented artist/animators. Yes, they may be in a class of their own, but you don't need nearly so many. Paying them does not need a big budget.
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
http://bp.io/wp/wp-content/uploads/2013/11/Img_Diffuse.png http://bp.io/wp/wp-content/uploads/2013/11/Img_Left.png http://bp.io/wp/wp-content/uploads/2013/11/Img_Right.png http://bp.io/wp/wp-content/uploads/2013/11/Img_Top.png http://bp.io/wp/wp-content/uploads/2013/11/Img_Silhouette.pn...
After manipulating some parameters, the software can then spit out a variety of maps, like these:
http://bp.io/wp/wp-content/uploads/2013/11/img_AO.png http://bp.io/wp/wp-content/uploads/2013/11/img_Depth.png http://bp.io/wp/wp-content/uploads/2013/11/img_Normal.png
As far as I can tell, it is indeed a simple radial gradient--but then the results of the layer-multiplication are put through some sort of palette-lookup function. I imagine it'd work sort of like palette-based animations (http://www.effectgames.com/demos/canvascycle/), but with the luminosity of the "light" at that pixel-position serving as the "frame number" of the palette.
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!
Now I'm off to upvote :)
As for types of lights and colors, yes, I think that would all be possible.
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.
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...
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...
I do a lot of research work with stereo, so thanks for the link! Have to give that a go sometime :)
http://forums.tigsource.com/index.php?topic=24094.msg958013#...
that generate normal maps from photos without human intervention.
What sprite lamp needs is integration with a 2d game engine. I'm not totally familiar with 2d engines, but they would have to support dynamic lighting with normal maps to make this work right?
My first thought was it is probably just a clever little convolution kernel trick but it seems harder after reading about it.
Now, if you were planning on doing some kind of dyanmic lighting in a web page, then sure, this would help. But I can't think of much use for dynamic lighting outside of games or other physical simulations, which is likely overkill for most webapps.