EverEnding DevBlog, November 2020: Shading

It’s been a weird month in a completely different way from the way that last month was a weird month. I started off trying to do more animation work, but found myself making very little progress – a few frames here and there, but so few I doubt the casual observer would be able to see the difference between the combined animation now and as it was when I posted it for last month’s update. Around this time I got the news that I was getting gently evicted – which became both a huge distraction, as I ended up moving by the end of the month (albeit a very short distance), and a pressure to reevaluate what I was doing.

Between that pressure and frustration with the difficulty of focusing on animation, I tabled that work for the moment. With my immediate future feeling suddenly a bit less certain, I started thinking about ways to monetize more of the work I’ve been doing. Over the last year or so of developing EverEnding for Unity, I’ve created a number of tools and assets which might be useful to other developers – however, in every case to make it useful would require dedicating a significant amount of time to documenting and polishing them, making them not only useful but easy to use, and also developing a store page and trailer for them. I decided the tool which I was most excited about and which was most likely to become profitable was the sprite shader – I originally just wanted a shader which drew shadow effects properly (which Unity’s standard sprite shaders don’t), but as I became more comfortable with the work I started adding features to it. For whatever reason, I find the work of describing how images get rendered to the video card, vertex by vertex and pixel by pixel, to be tremendously exciting. It’s fun in much the same way as art, but at a slight remove – a distance which makes things more awkward but also grants you the kind of power and leverage a brush or pencil can’t provide, the power to immediately change everything about the way an image looks with just a few lines of code.

I got shadows and lighting working for my sprite shader a few months ago, but I didn’t really understand that much of why they worked. This month, I went through most of Catlike Coding’s Unity Rendering Tutorial series, which demonstrates how to create a generic all-purpose shader from the ground up and which I’d highly recommend to anyone interested in this field, and pulled in every idea which seemed like it still applied to a 2d surface. As I went I added in most of the features of those shaders – Multiple light sources, semitransparent shadows, normal mapping, BRDF shading – as well as several other effects, such as Photoshop-style blend modes.

Additionally, I began work on a special ‘modify’ mode which applies the color transform and displacement effect to whatever’s behind the sprite using the sprite as a mask. This actually raised some questions about how exactly this ought to work – should the displacement effect displace the pixels of the sprite used as a mask, or should it displace the pixels behind the sprite used as a mask? Should alpha alone determine effect magnitude, or should it be based on the individual color channels, or should it be based on the total pixel luminance? Because of these questions and complexities, I’ve split the modification mode out into a completely different shader rather than making it a feature of the sprite shader.

Over the last couple weeks, I’ve realized that in general I’d fallen overly in love with the idea of one sprite shader that can do everything. Thinking about it logically, there’s probably no scenario where you’d need one sprite to both draw as a solid opaque cutout which casts shadows and to have a custom blend mode – so now rather than one ultimate sprite shader, I have three which should cover most or all use cases: The depth sprite shader, the blended sprite shader, and the modifier sprite shader. It might be a bit harder to brand than an ultimate sprite shader, but I think it will be more usable, since all of these special features were getting more and more difficult to organize and optimize.

All of this stuff mostly works right now. Some of these blend modes required me to sample background pixels in the shader, which Unity provides a method for, ‘grabpass’, but which method is both unreliable and inefficient, being kind of a black box – this was causing huge issues, since exactly when the grabpass happened relative to the rest of the world getting drawn wasn’t exactly clear and seemed to be changing based on the position of the camera. Fortunately, I found a very useful resource on how to implement most of the most common blend modes without using grabpass. I may go back at some point and make another sprite shader that uses grabpass to implement the other blend modes, but it seems unlikely to be necessary given the vast range of possibilities offered by both the blended sprite and modifier sprite shaders.

As an example of something that can be done with the blended sprite, I’ve created a paper overlay texture – this actually has a normal map, so it’s not just a static overlay but changes with lighting

This paper overlay is an effect I’ve really wanted to get working since the very beginning, since I think it adds a lot to the sort of storybook presentation I’ve been going for. At the moment it looks a bit odd having everything move across the paper as the player moves while the paper itself stands still – I’ll probably change it so the paper texture scrolls with movement at some point, but that change is relatively trivial compared to the work put in getting this overlay effect working in the first place.

Anyway, that’s what I spent the first few weeks on. The last couple have been mostly dealing with moving, and dealing the exhaustion that comes in the aftermath of moving. Unfortunately this move is probably only a temporary solution, and I’ll likely have to move again sometime in the next 6 months – at least now I know what’s involved and can plan ahead a bit better.

So what’s next? I still need to finish up the sprite shaders – mostly done, but there’s a couple of features I’d still like to add, documentation to write up, and a store page to make. I’m hoping that can pull in a bit of cash over the next year, and once that’s done I’ll probably go back to do more animations and/or pick another tool to get up and running on the asset store. December’s likely to be a not-especially-productive month, though, as that’s usually the case with Decembers.

If you’d like to help support this project or my writing, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.

Leave a Reply

Your email address will not be published. Required fields are marked *