Sprite Lamp and Unity

So, finally proper update today, and a new release of the Sprite Lamp Unity shaders to try out. Apologies to all for the time this took (and to anyone wondering, Snake Hill is just about ready for the fire season).  You can get the new shaders at the Sprite Lamp engine page as usual. Here I’m going to write a few things about Sprite Lamp and Unity that might be relevant to you. I’m going to make a quick disclaimer here now though: I’ve been tinkering with Unity for a little while, but I’m not expert – if you read something here and think you know better, you may well be right, and please let me know!

Normal maps in Unity without special shaders

I think with all my talk of Sprite Lamp/Unity shaders, some non-technical (or just non-graphics-savvy) readers might have gotten the impression that you have to use my official Sprite Lamp shaders to use Sprite Lamp with Unity. This is not the case! Sorry if I communicated that poorly. Sprite Lamp creates normal maps, and pretty much any modern 3D game engine that supports dynamic lighting, including Unity, can work with normal maps. As far as the engine doing the rendering is concerned, applying a normal/bump shader to a sprite is no different to applying a normal/bump shader to a mesh. The key thing with Sprite Lamp is allowing normal maps to be created without 3D modelling, and in a fashion that maximally preserves the artist’s style – but at the end of the day, they’re still normal maps and can be used like normal maps! There are some special fancy shader effects that work well in conjunction with this technique – stuff like self-shadowing based on a height map – and I’m writing my official Unity Sprite Lamp shaders to support those effects. But, I’d say most people working with Sprite Lamp would get most of what they want with Unity’s built in shaders.

That all being said, this is simple enough to do. First thing you’ll need is a diffuse map and a normal map (which I’ll presume is made in Sprite Lamp, but need not be). Import both these images into Unity in the usual way, with the diffuse map set as the Sprite type, and the normal map set as the Normal type. It’s important at this point to uncheck the ‘Create from Grayscale’ checkbox on the normal map’s import settings, or else it will look (and be) incorrect.

From there, make a new material and set the shader as one of Unity’s built in shaders with ‘bump’ in the name, such as ‘Bumped Diffuse’. You can now drag your textures into the appropriate slots, and drag the material onto your game object. This can be a sprite you created, or a quad (or a mesh of some other shape).

The advantages of using Unity’s built in shaders are mostly that, now and in the foreseeable future, the people that built Unity understand Unity better than I do. :) They’re likely to have more complete support across all of Unity’s different iterations, different platforms, rendering backends, etc. and, if nothing else, can hopefully provide a fallback if my shaders aren’t perfect. The good people at Unity are likely better optimisers than me, too, especially for mobile platforms where it counts.

The official Sprite Lamp Unity shaders

There’s a detailed writeup of how to make use of the official shaders over at the engine integration page so I’m not going to reproduce that all here. What I will do, is describe what’s changed in this new update – in dot point form.

  • Spine – My first attempt at a Spine shader is now included.
  • Attenuation that works properly – To my mind, this was the biggest problem with the old shaders – they weren’t terribly usable when you couldn’t reliably avoid nasty hard edges from the lights going out of range. It should be sorted now. You still have some ability to tweak attenuation of lights on a per-material basis (which I still wish I could make a property of lights).
  • Spotlight circles need no longer be hard-edged (how soft they are is also adjustable in the material properties).
  • Optimisations – I’ve revamped how a few things work, and that should make things faster (fewer branches due to multicompile between different light types is the main thing).
  • There are a few platforms that this didn’t compile on before that it now compiles on. If it still doesn’t compile for you, let me know (these things can be hard to track down).

I’ll also add that I’ve decided to keep the ‘several shaders with different features turned on and off’ approach, rather than attempting multicompile stuff, because as far as I can tell this would cause a mild combinatorial nightmare because it is also compiled five times for the different light sources.

Somewhat experimental Spine stuff

I’ve gotten some lit Spine stuff working at my end. I’m not sure that this is the best way to go about things, because I’m even less experienced with Spine and Unity together than I am with Unity on its own, but hopefully it will be of use to some people. It makes use of a fragment shader that calculates the normal/binormal/tangent matrix on the fly, so it can deal with deforming meshes without requiring a bunch of extra code on the CPU side to calculate tangents dynamically as they deform – not sure if that’s the best tradeoff (my guess is that it depends on the platform).

For this reason, it should be reasonably simple to set up, with one exception that I’ll get to in a minute.  Start by setting up a Spine character (or whatever) in Unity the way you usually would – I won’t go over this here because there are better tutorials to be had by googling. When things are working as they should be (but without lighting), there’s one tricky thing to do (and thanks to ashwin911 from the forums here for putting me on the right track with this), which is setting your Spine object to have some Z spacing.  This is because multipass lighting in Unity  depends on the depth buffer, so we’ve got to give it different depth values. There’s a value called zSpacing that you need to set to some small negative value (ashwin911 suggested -0.001, which is what I’ve gone with in my example). The trick is, this value is hidden for some reason, so you need access to hidden variables. You can do this by going up to the “inspector” tab, right clicking, and selecting “debug”. Under the “Skeleton Animation” component, there should be the ‘ZSpacing’ value available to change.

Once you’ve set that to -0.001, you can create a material using the Sprite Lamp Spine shader, and assign your textures to it as usual. From here, assigning your material to your Spine character should be all that’s left!

The new attenuation stuff

I’ll just mention very quickly how I’ve set up attenuation. Basically, it works by calculating a linear drop off in intensity, that goes from one at the origin of the light, to zero at the max range of the light. It then raises this value to a power – you have control over that power, in the ‘attenuation exponent’ shader variable. If you increase this variable, the dropoff will happen suddenly, quite close to the light, then go to zero very gradually. If you lower it, it will drop off gradually at first then suddenly near the end. Lowering it all the way to zero will give you a bright sphere that drops to zero immediately at the maximum range.

Similarly, there’s a variable called ‘spotlight hardness’, that affects how hard-edged the circle of a spotlight will be. This is pretty self-explanatory – setting it to maximum will make the spotlight a hard-edged circle like it was in the older shader, and setting it lower will make it very soft-edged. Unfortunately, both these variables are attached to the material, not the light source (I’m not sure if it’s possible in Unity to attach variables to the light source).

Recent issues

This is a pretty boring post, but I didn’t want to go silent for too long. I just wanted to let people know that work continues on Unity shaders and the Mac port. Things have been slow lately, partly because there is a rather full on week of conferences for game developers in Melbourne (GCAP and PAX Aus happen within two days of each other), and partly because of random personal stuff (mum’s recovering from knee surgery and we’re approaching fire season so there’s been a bunch of stuff that needs doing), and then to put a final annoying conclusion on the whole thing, my computer crapped out yesterday and (seemingly) has to be replaced. Stuff is backed up so no worries on that front, it’s all just inconveniences. Sorry for the somewhat whiny and very unexciting post, but as I say, I figured I should say something so people don’t think I’ve died or abandoned Sprite Lamp. I realise there are folks out there hanging out for updates, particularly Unity-related stuff, and I’m sorry for the time it’s taking getting things done. At least the next couple of weeks will probably be an improvement.

Unity shader update/info (minor)

This isn’t quite the update I wanted to make, but it’s something. I’ve just uploaded a new example project and Unity package stuff to the engine integration page.

Working with Unity’s shader system has been a big learning experience, and I’m slowly coming to understand how it all works (and how my initial attempts have failed to do things The Unity Way, as it were). I’m in the process of reworking the shaders to make use of the (startlingly deep) Unity shader macros, and when that’s done I’ll post another update, and it will cause attenuation and light cookies to all work in the nice simple way you’d expect Unity stuff to work. In the meantime, this smaller release fixes the problem a few people have reported involving weird specular lighting appearing where the alpha channel is set to zero and should thus not be visible (this turned out to be a schrödinbug relating to multipass lighting and blend modes), and adds the experimental new implementation of per texel lighting (both the palette and regular shaders have new versions with this feature).

I should also mention something that came up on the forums, which is an unfortunate development regarding performance of Unity on mobile platforms. It seems that Unity2D relies heavily on dynamic batching to keep its performance up to acceptable levels on mobile. However, dynamic batching gets broken by multipass lighting, which is how Unity handles all per-pixel lighting as far as I can see, and so this is causing some performance issues. I currently don’t have a good solution to this – for a while it looked like this would be solvable with a hackish application of Unity’s per-vertex lights, and making use of them in a special fragment shader, but I’m not really comfortable claiming an official solution to a problem that involves such unofficial methods (and I definitely shouldn’t promise they’re going to work on all present and future platforms Unity supports!). One possible solution is static batching, but that’s a Unity Pro feature. Another possible solution is a script that automatically groups tiles together into bigger tiles, which is essentially a custom static batching solution – I’d happily write such a script and distribute it if it would help people out. I’ll keep looking for solutions. In the meantime, you need not buy Sprite Lamp to test such performance issues on your game/hardware – any normal map will do the job.

Steam release, new website, and forums

So! The big news, I suppose, is that Sprite Lamp is out there! In the wild. What’s unusual is how late I am to post about this, but main point is, Sprite Lamp for Windows is on Steam right at this very moment.

The reason I haven’t posted about this yet, despite the Steam release being last Thursday, is that I was hoping to get Sprite Lamp out in its DRM-free form at the same time. I’ll be doing this via the Humble Widget, and I suspect rather strongly that a lot of people would rather own a tool like Sprite Lamp in a more traditional way, rather than having to boot up Steam in order to use it. For that reason, I’ve been holding off on talking much about the release. In other words, I don’t consider it really released until the DRM-free version is out there. The issue is that because I want it to be possible to upgrade from the Hobbyist to the Pro versions of Sprite Lamp, the good people at Humble tell me it takes a bit longer to set up the widget, and that I’ll have it early this week. Big announcement when that happens, of course.

Regarding the new website, this is for a couple of reasons. The old website made use of wordpress.com, largely because I set it up way back before I knew where Snake Hill Games was going, and wanted something easy to deal with. Gradually, there have been more and more things that I wanted to be able to do that I couldn’t via wordpress.com, but it has come to a head by learning that I couldn’t use iframes and thus couldn’t embed the Humble Widget. This isn’t the first thing I’ve been wanting but unable to do with the website, but it’s the first that is an unambiguous show-stopper, so the switch had to be made.

This has a few benefits. For instance, Snake Hill Games now has a forum! This has been a long time coming (shout out to my friends at Graphite Lab who helped me out with some initial forum attempts earlier – it was only because of my foot-dragging that that didn’t happen), but you can now come to the forums (link near the top of the sidebar on the left) and say hello. I’m not overly familiar with the running of forums, and I’m not expecting them to explode into a huge bustling community or anything, but if you have problems or suggestions or want to show off your artwork, head on over – I apologise in advance if I screw up the administrative side of things.

Obscure Unity/Surface Pro 2 problem solved

Okay so this is a post that has little to do with Sprite Lamp. In fact, it’s probably not interesting to most people who have subscribed – sorry about that. It’s about an obscure problem I had today that I seem to have fixed, but couldn’t really find anything about it online. So I post it here, on the off chance that someone else has the problem and maybe googles their way to this page, and maybe can waste slightly less time on it than I did.

I’m using a Surface Pro 2 (the 256GB model, though I doubt that matters), and was going to do some work in Unity3D. I hadn’t run Unity for a little while, and when I fired it up today, it had some problems. Specifically, lots of messed up visual stuff. Unfortunately I didn’t get a screenshot, but to my eye it looked like some fairly low level VRAM corruption of some kind… within the Unity Editor, various things were messed up, including button and other UI graphics being busted, text was garbled and screwy, and various texture previews were busted. Interestingly, it seemed to also screw up some of the actual game assets when rendering in the viewport.

Anyway, I tried the usual raindances, restarted Unity, restarted Windows, etc. to no avail. My graphics drivers were up to date, so that seemed all good. However! Long story short, a couple of people have reported that using Intel’s generic drivers rather than the ones Microsoft provides with Windows Update can help with some gaming applications (plus it gives you a control panel to mess with certain options), and I had actually done this on my Surface some time ago – but, I had since reinstalled the OS and obliterated the changes. Also, Unity never used to have this problem… curious. So, I got myself over to Intel’s driver page, navigated to the HD4400 area, and got the drivers from there. And that seems to have fixed it! Happy Unity shader editing since then, and all is well in the world. So if, by chance, I’m not the only person to have ever had this issue, and one of the other poor souls happen to wander here in their confusion, there you go. It’s what worked for me, anyway.

Sprite Lamp for Windows launching really soon

Hi folks!

So I guess I’ve kind of given away the main bit of this in the title. There’s a bit of a story behind it, but the TL;DR is that Sprite Lamp for Windows will be launching on Steam on the 25th of this month! Yes, that’s in a few days – this Thursday in fact. I’ve got an application pending for a Humble Widget too, so while I can’t 100% confirm it, I’m hoping that it will be available via Humble Widget (at www.spritelamp.com) on the same day, or at least soon after.

There’s a bit of a story leading up to this which I’m going to tell now – not because it’s particularly interesting, but just for the benefit of people who like to stay informed about adventures in development.

Recent events

My initial plan was to launch a bit earlier, on the sixteenth. I just had a couple of things to do, and one of them was to ask the fine folks at Valve how to tag it as ‘early access’. This would have been on something like the ninth of this month. What I learned when they replied is that Steam’s Early Access feature is for games, not software in general, and as such Sprite Lamp can’t make use of it. Sprite Lamp is in a pretty good state now I think, but there were definitely some bugs still there and I was also hoping for some wider feedback on the UI and general usability issues, so this was bit of a rude shock (NB This was my fault, not Valve’s). I briefly considered delaying, but on further reflection I concluded that:

  1. The serious bugs that remained were probably fixable in a week or so of furious coding.
  2. Though the software will continue to improve in the future, it’s at a point now that people will find it useful for their development, and by delaying it I’d just be keeping it out of people’s hands unnecessarily.
  3. I’m inclined to be pretty nervous about launching products and that’s probably making me cringe away from this situation a bit, but I should correct for that personal bias of mine and just get on with it.

So, steeling myself to a week of reasonably full-on bug fixing and polishing, I got into it! At least, I wish that’s what had happened. What actually happened was that my computer died. Totally random, by all appearances, but not ideal timing. No data loss, but certain set things back a bit. I was back up and running in a few days, delayed the launch by a small amount, and got to work. Fortunately, I was right about being able to get through the bugs on my list in a few days, and that brings us to where we are now. Despite a slightly hair-raising last couple of weeks, Sprite Lamp on Windows/Steam is ready to go!

MacOS and Linux versions

So, I mentioned in my last post that I was going to stagger the launch, because it’s a small team and I’m not familiar enough with MacOS and Linux development, and in general, it’s scary enough launching a product on Steam without throwing in multiple OSes at the same time. However, I’m pleased to announce that the MacOS build is making really good progress. I’ve had my head in Steam stuff for a little while now, but the MacOS port has made enough progress in my absence that it’s time for me to get back into that side of things (that is, it’s reached a point where my knowledge of Sprite Lamp’s codebase will speed things up greatly). Though I’m reluctant to make solid announcements, I’m pretty confident that we’ll have at least something beta-ish in a few weeks, and I’m hoping for the proper launch within a month of the Windows launch.

The Linux build of Sprite Lamp has historically been way ahead of the MacOS build, but I’m afraid that will change at this point. However, it’s definitely going to be following the MacOS build pretty shortly.

Depth editing and imminent update

Hi folks. Just another Sprite Lamp progress report. Before I go into that, I want to give a shout out to two projects that are on Kickstarter right now that are making use of Sprite Lamp. First off, Hive Jump – a 2D shooter with local co-op, and with plenty of dynamic lighting to show off. Secondly, Elysian Shadows, an RPG with some next-gen lighting techniques – they’re not as far along with their Sprite Lamp usage but I’ve been in touch with them about it and they’ve got some sweet stuff planned. Both projects seem to be kicking some arse already funding-wise but you should still go and check them out.

Next Sprite Lamp release

So, I said in my last update that it would be the last time I do an update via the moderately dodgy dropbox link method, as I’d be moving to Steam. I was hoping to make good on that plan, but getting up on Steam is taking me a little longer than expected, and I’m currently sitting on some features that I want to put into backers’ hands sooner rather than later. As such, there’s going to be one last pre-Steam release, and it will be some time over the next few days. This also means one more release with a dodgy not-so-useful Mac version, unfortunately, but see below for some more encouraging news on that front. I’ve been hard at it on the features though, so this next update should be a good one. For everyone, it will contain the Spine integration that I mentioned a couple of posts ago, which is already pretty cool. For pro users, it will also contain the long-promised depth editing system, which I’m about to talk about. There are also a couple of other small improvements and tweaks to things I noticed needed fixing along the way.

Depth editing tools

As mentioned, this is a pro-only feature. Just wanted to get that in early to avoid any disappointment. One of the major things I’ve been working on is a system for editing and fine-tuning depth maps after Sprite Lamp has created them. As you might know, Sprite Lamp is primarily for creating normal maps, but can also create depth maps from them. However, there isn’t enough information in a normal map to create perfectly accurate depth maps, and in some cases the results could use some tweaking (particularly for elaborate character art or other complex objects). Drawing depth maps from scratch is a pain, though, so I wanted to add tools to build on what Sprite Lamp has created so you can get good results without loads of work. Sprite Lamp’s workflow for tweaking depth maps is roughly as follows:

1. Select edges between pixels where there is a depth discontinuity.

2. Select pixels in the depth map – a process which is aided by the edges from step 1 – that are at the wrong depth (say, the pixels of an arm that need to be brought forward).

3. Move the selected pixels forward or back until they’re in the right place.

4. Repeat until things are as you want them to be.

The depth editing interface looks like this:

DepthEditor

In the preview window you can see the place where you actually interact with the image. The red lines are the edges between the pixels. The cyan lines are contours (their display can be toggled) which helps you see problems with the depth map. Edges can be detected based on various things (such as sharp changes in the normal map or the diffuse colour), or painted directly with the mouse. Selection is also painted with the mouse, although factors such as softness can be controlled, as well as only selected pixels of similar depth to where you started (important for selecting creases and the like). Selection is necessarily soft, because if you have a hard-edged selection and pull bits of it forward and back, you’ll get a big step in the depth function, which isn’t usually what you want.

You’ll also notice that there’s an undo and redo button, which kind of goes without saying with tools like this, but I still wanted to mention it because it was such a pain to implement.

I’ve since gone back to some of the Sprite Lamp test artwork that caused problems for the depth generation algorithm and done some work with the depth editing tools, and so far it has taken me very little time (usually five to ten minutes of messing about) to get things to a good state. I admit I’m not all that sure how many of Sprite Lamp’s userbase will be making extensive use of this feature but I think those that want it will be pleased with the results.

Progress on the Mac port

One of the reasons I haven’t been super talkative about features recently is that I’ve been working on some major refactoring. For the non-programmers reading this, ‘refactoring’ is another word for ‘working really hard and producing no visible results’ – in other words, I’ve been reorganising the guts of Sprite Lamp rather than adding features. This is to make things as quick and painless for the Mac port, which I’m pleased to say is now underway. I mentioned it was underway last time I think, which it was in the sense that I’d confirmed with Rob that he wanted to work on the project and he was looking over the code. Now it’s underway in the sense of code is being written and the MacOS UI is being built. This is pretty exciting for us over here, since Halley (who you may remember as the artist who has done pretty much all of Sprite Lamp’s sample art from the Kickstarter and these blog posts) is a Mac user and is very much looking forward to getting a real copy of Sprite Lamp up and running on her machine. I know there have been some people hanging out for the native Mac version, so I hope the news is good for them too.

Remaining features

The list of tasks remaining on Sprite Lamp isn’t empty, but it is getting pretty short (note that I’m not talking about engine integration stuff for the moment – there’s certainly plenty of work left to do there). I’ve still go a few things I still want to add, though, and I wanted to give people some idea of stuff that is still coming. Two major-ish features that remain on the list, both pro features, are the ability to load custom shaders for the preview window, and the ability to export a mesh based on the depth map you’ve created. Another feature that I really want in is the ability for all the map generation functions to be interruptible – currently they just block Sprite Lamp, which is fine for pixel art because they take a fraction of a second, but it’s a bit awkward having Sprite Lamp basically hang for ten seconds or so while a higher resolution image processes – I’d much rather there was a progress bar and a cancel button. That one’s a substantial task, but I think it would seriously improve the user experience and the usefulness of Sprite Lamp, especially when you’re experimenting with different settings. I also have a few features that aren’t accessible to the command line interface yet that I need to add, namely anisotropy map and palette creation. Finally, if people want it, I’m still up for making a native-looking UI for the Linux build. I feel less urgency on this one, because the Linux implementation of Winforms is actually really stable and responsive as it turns out, but unless people overwhelmingly don’t care, I’ll get to it.

At this point, though, I think that as far as 90% of users are going to care, Sprite Lamp is feature complete, and for the other 10% of users, Sprite Lamp is very close to feature complete. For that reason, I’m going to focus on getting everything aligned for the Steam release and the mac port, and then dive into the more complete engine integration – the features I’ve just mentioned will come after that. I just wanted to mention them in case anyone was worried I’d forgotten about them.

Sprite Lamp release plans

This is the post where I talk about the near future of Sprite Lamp and releasing on various platforms. Yesterday I posted about Spine integration, and I’m also working on the tools for editing depth maps. There are a couple of other smaller features I’m hoping to have added at some point, such as loading of custom shaders, but when the depth editing is done, Sprite Lamp (the standalone application, for Windows) is getting startlingly close to finished. Given that, I’m going to try to make the next release a Steam release. Fingers crossed, I can make this happen in something like the next couple of weeks.

Questions of Steam early access

I’ve given a lot of thought to early access, because I have slightly mixed feelings on it in practice. I don’t want to be ‘one of the bad ones’ – I feel like there’s a certain amount of frustration going around with certain early access projects for various reasons, and I don’t want Sprite Lamp to be one of those.  On the other hand, betas are useful for various reasons, and a platform like Steam is a good way of carrying them out. There can also be hiccups in the implementation of being on Steam itself – it’d be nice to have a chance to make sure Steam-specific things work (for instance, upgrading from hobbyist to pro will be done using the DLC system, I need to make sure that works smoothly) before it goes to a bigger audience.

So I’m pretty open to suggestion on this strategy, but currently I’m thinking of trying to get the Windows build out as a closed beta (which will involve me trying to get Steam keys to everyone who has already got Sprite Lamp by Kickstarter or through PayPal). Once that’s sorted, we’ll go into early access – at that point, it’ll be at the current (slightly) discounted Kickstarter/early price of $35/$90. When it releases fully, it’ll be for $40/$100. I’m going to try to make this early access period as quick as possible, though. During the early access period, I’ll also try to get a maximally polished Linux build onto Steam. The current Mac build isn’t really Steam-ready, though – a fact probably known to those who have tried using it. That brings us to the next section.

Sprite Lamp for MacOS

For a while I’ve been in contact with a fellow I know by the name of Rob Caporetto who was potentially going to help me out with the native UI version of Sprite Lamp for MacOS. He’s got some experience with MacOS and C#, which isn’t the most common combination of skills, so it seemed pretty ideal. Unfortunately he wasn’t free to work on stuff until fairly recently, but I’ve been in contact with him and he’s had some time to look over the source code. We’ve talked about what needs to be done and how to do it, and come to some conclusions:

  • It’s probably not worth holding up the other releases to wait for this one. I didn’t make this decision lightly, because I had always wanted a simultaneous release, but at the same time, it seems pointless to keep a working build out of Windows and Linux users’ hands just for the sake of that (especially when those two groups are likely well over half the users).
  • There’s a small amount of work for me to do on the codebase to get it ready for porting, which I’m going to jump into as soon as the depth editing stuff is done.
  • It’s probably somewhere in the ballpark of a month of work. As such, I’m going prioritise doing as much as possible of the port stuff myself, especially the grunt work, and Rob can spend all his time on the hard bits. That way it’ll be in Mac users’ hands as soon as possible.
  • More than was the case with the rest of the development, we’ll be able to prioritise the adding of features so that the most commonly used ones are in first, and as soon as we have something pretty usable, we’ll put it out there (on Steam, if we’re at that point by then, or otherwise in a regular update).
  • More as it develops.

So, that’s that. I’m pretty damn excited to see the first build working on MacOS, but not half as much as Halley is (being the artist behind Sprite Lamp’s sample art, and a mac user).

More engine integration

The other part missing from this story is the future of engine integration. More than any other part of the development of Sprite Lamp, engine integration has taken me off guard scheduling-wise, because it’s hard not to get tangled up in small details when you’re working with unfamiliar tech. However, once this next release is sorted, I’ll be able to get into doing some of the integrations closer to full-time. First priority will be Unity since so many people use that, then I’ll look at rejiggering some of the Game Maker stuff, and then basically I’m going to go through the history of people requesting engine integrations and try to get as many sorted as I reasonably can. So far I’ve been including engine integration stuff with Sprite Lamp, but when there’s a bit more complete I’ll be making them all available for free download here.

Sprite Lamp and Spine

As I’ve mentioned recently, I’ve been playing with Spine and Sprite Lamp. It’s time to talk a bit about how that’s going and what it means.

Spine files in Sprite Lamp

The main thing I’ve been working on lately is loading up Spine files in Sprite Lamp, so you can view them, animated and dynamically lit, in Sprite Lamp’s preview window. And, it’s working! It looks something like this:

Sprite Lamp with an example Spineboy animation loaded
Spineboy artwork and animation is from Esoteric Software, with our own lighting profiles/normal maps applied.

As you can sort of see from the screenshot, the interface is not terribly complex – you load up a .json file and you have your character. You’ll also need to (draw and) load up lighting profiles in atlas form (if the files are named properly Sprite Lamp will automatically grab them), and then off you go. You can select any animation in the Spine file and also select different skins. You can also control the speed and direction of the animation playing.

The walk is a bit slower than I’d like, perhaps, but here’s an illuminated Spineboy, with a static light to make it easier to see what’s happening:

Spineboy walking with dynamic lightingThere’s a certain amount of dodginess regarding the bending of the knees, though for artwork that was made without dynamic lighting in mind, I think he came out pretty well. The fact that this is truly dynamically lit, rather than just faked, is most evident on the parts that are rotating the most, particularly the right hand.

The intricacies of rotating normals

It might be helpful, particularly for programmers, to have a bit of a grip on the maths behind this kind of thing. If that’s not your bag, you might want to skip this section.

It’s tempting to think that all you need to render a normal-mapped Spine character is the ability to render a normal mapped sprite combined with the ability to render a conventional Spine character. Unfortunately, the rendering side is slightly more complex than that (NB: I’m just talking about the shader maths here – these complications are not the artist’s problem).

Naturally, rendering a Spine character involves moving and rotating various images about. This is nothing special – rotating a textured quad is something computers have been able to do happily for decades, after all. You paint your character’s leg image or whatever, then you rotate it, and you’re all good. However, when normal maps become involved, things get slightly more complex. If a normal map has a pixel that encodes a vector that faces to the right, and you rotate the whole image 90 degrees clockwise, that pixel should now be facing down. But, its colour hasn’t changed – it still encodes ‘faces to the right’. If you rotate it another 90 degrees, so it should be facing to the left, it still appears to be ‘facing to the right’. This problem gets worse the more the character rotates. Some Spine enthusiasts reading might remember ages ago when Sprite Lamp was in its Kickstarter phase, we had a few shots at Spineboy walking around with dynamic lighting. If I recall correctly, this problem was present in those demos. It was very subtle, because no part of Spine Boy rotates a huge amount during his walk cycle, but it was there. Fortunately, the solution is not terribly complex – you simply have to tell the shader how much each body part has rotated from its default position, and rotate the normal by that amount in the pixel shader Done!

But, you might justifiably be wondering: what of soft skinning? After all, the fine folks at Esoteric Software have been hard at work following their recent Kickstarter adding soft skinning and free form deformation (FFD) to Spine. It’s not obvious what it means to refer to ‘rotation’ when the rotation of a point is going to vary throughout a mesh. And, indeed, this does get a bit more complicated. For Sprite Lamp, I’ve decided to go with a fragment-shader solution to this problem. It involves using the derivative functions in GLSL to compare the the world position and UV coordinate of a fragment with its neighbouring fragments, which enables you to calculate a thing called a TBN matrix (tangent, bitangent, normal). When this release comes along, I’ll talk a bit more about how this is done in the shader. The takeaway is that in the next release, Sprite Lamp should smoothly handle all the different types of animation Spine can throw at it – textured quads, but also soft skinning and FFD. As a demonstration/stress test, Halley has cooked up a slithering snake animation. She wanted me to make it clear that this is not her best work and she’s not very experienced with Spine animation. As far as a clear demonstration of variable rotation on a soft-skinned mesh, though, this does nicely:

Snake slithering to the leftYou can see here that with the light source on the left, the coils of the snake are picking up the lighting correctly as they wave. It’s not obvious for all animations when the normals aren’t being computed correctly, but in the case of this snake it’s something of a stress test.

Spine and Sprite Lamp in your game engine

So, so far the work has been on getting Spine animations displaying in Sprite Lamp. You might be wondering when you can actually put this in your game.

Unfortunately, the answer to that depends on a bunch of factors. I’m only one programmer, and the crossover between Spine and Sprite Lamp is only one of the many parts of Sprite Lamp. Once Sprite Lamp is out (like, out out, not in alpha like it is now) I’ll be able to give a much more thorough look into engine integration. My policy with Spine will be similar to my policy with the rest of Sprite Lamp’s engine integration: I’ll do as many as I reasonably can myself. Since there are a lot of engines in the world, and I can only cover a few of them, I’ll also do my best to document everything you need to know as a programmer to get things working yourself, be it in an existing game engine that I haven’t been able to cover, or in your own hand-coded system.

That all being said, somewhat predictably, my priorities towards the most widely-used engines will remain, meaning Unity will be first on the list. I’ll be posting more of that as I know it.