Seeking critical feedback of a tool idea for 2d sprite lighting. (not promoting)

Looks interesting, but to me it's not clear at all what you talk about.

Does it need 3D geometry as input?
What's the output - many images for various light angles? Or some per pixel data structure returning occlusion from a given direction?
Would the column also cast shadow to a ground made from other tiles? What's the limitations?

Basically - how does it work?

Love the geometry here — the faceted shapes catch light in such an interesting way. But how it differ from regular baking or whatever?

Thanks for the response,

What I currently have takes 3D geometry as input. The output is a per pixel data structure which needs to be sampled by a shader at runtime which samples per pixel data structures along with light directions / position uniforms.
The biggest limitation as you mentioned would be that there is no shadow casting only self-shadowing.
another one in particular is the file sizes for 512x512 sprites would be around 4 mb which would be quite a significant increase.
There can be some inconsistency with shadowing complex meshes. I haven't noticed a lot of issues with the technique for shadowing solid objects but a sprite which has depth complexity i.e a steel cage I have noticed can have some inconsistencies with detailed shadowing though.

Reminds me of D.O.R.F., they did something very impressive with their sprite tech. But honestly, I don't think most indies making a 2D game want to model 3D models first and then render them. Because then they could just as easily make it into a 3D game.

The main benefit of 2D pixelated sprites is that you can get it done much faster than 3D. Indies don't have the budget / time to be making lots of 3D models. Which is why you get so many asset flip games. Often, they don't even take the time to make their own sprites, which is embarassing, but sadly true. You are presenting a high quality technique that is only suited for bigger budget productions, because it essentially forces you to make a 3D game, and then just bake it down into high quality 2D.

Something like what Smack Studio is doing is more suited for indie 2D games. But you'd have to roll your own if you wanted to add shadows to it, because they only allow a sprite sheet export with only colour values, not normals, etc..

That's really insightful, works ok in current form for 3D but your right. I would have to explore if a good workflow can exist for dedicated 2D. If use case for this type of lighting would be viable with 2D and have enough value over current real-time solutions.
Also mitigating some of the drawbacks i.e. file size requirements etc. would be an area to explore for me. Really appreciate the answer.

Low-end machines don't just have less processing power, but also less memory bandwidth, and not even dedicated video memory (if we're talking laptop iGPUs or mobiles, or even the steam deck, afaik). Which means you really want to limit the number of texture fetches per pixel shader invocation. AFAIK, they even share the L3 cache between the CPU and GPU part. On many of those devices, the L3 cache can't even hold a single fullscreen RGBA buffer, so you end up cache missing a lot and have very long roundtrips to main memory.

Geometry is not actually the bottleneck usually, as long as it's just normal vertex transform stuff and the vertices aren't too bulky. The expensive part of 3D is having bulky vertices that have all kinds of information, and then also multiple texture fetches per pixel, and small triangles that throw away lots of pixel shader results (because you always get a 2x2 batch of pixel shaders evaluated, regardless of whether all of them are inside the triangle). And of course lighting, too.

In 2D, you usually have comparatively little geometry on screen (far from the millions of triangles you'd have in 3D games), but you usually render in blend mode a lot because of the transparency. The vertices are usually more lightweight in 2D, too. I think more useful in that case would be to have a tool that splits a sprite into fully opaque and partially transparent areas, and also cuts out any fully transparent areas from the sprite geometry, instead of using a naive quad. Then you can utilise the z-Buffer and render front-to-back, without overdraw, and then apply the transparent parts back-to-front in blend mode.

That's something that would help 2D games in general, and especially on low-end hardware where you don't have dedicated VRAM to hold the draw buffer in. I think in general, lifting per-pixel data into triangles has a lot of potential, especially since 2D games almost don't use the vertex processing capabilities of the machine at all. And maybe then you can also end up with lower resolution textures.

RmbRT wrote:

The main benefit of 2D pixelated sprites is that you can get it done much faster than 3D.

To me this argument feels a bit like a myth. I can make a low poly Quake level faster than drawing bitmap tiles. I can model and animate low poly characters faster than i can draw sprites.
I would say 'it depends'.
Also, thinking of an isometric game where shadows make much for sense than with side scroller or top down, 3D modelling is probably the default workflow anyway.

To me the biggest problem is the 'only self shadow' restriction. They shown example is beautiful. But what doe sit help if my columns show no shadow on the floor? It's probably better than to have no shadow at all, for consistency.

Eventually this could be solved by baking for a whole level, not just single tiles. Eventually on client and not offline, to avoid storage and the production burden.
But then you end up working on engine tech, not just a tool.

But not sure. Showing example results from your game might help with such doubts.

The example pillar is not 2D art, it is 3D art. It is competing with straightforward rendering of simple models in a 3D game engine, not with shading large and complex sprites by hand for use in a 2D game.

RmbRT said:
I think more useful in that case would be to have a tool that splits a sprite into fully opaque and partially transparent areas, and also cuts out any fully transparent areas from the sprite geometry, instead of using a naive quad. Then you can utilise the z-Buffer and render front-to-back, without overdraw, and then apply the transparent parts back-to-front in blend mode.

Actually, I just stumbled across Anti-aliased Alpha Test: The Esoteric Alpha To Coverage, as I was trying to get a better grasp on the GL_SAMPLE_ALPHA_TO_COVERAGE feature. So what you really want is the ability to do alpha to coverage on areas of a sprite that are either fully solid or fully transparent, and then true alpha blending on areas that are partially transparent or on sprites that are not rendered at full opacity. You may still want to cut out fully transparent parts even then, though, just so that you save on pixel shader invocations for the transparent regions. But at least alpha-to-sample-coverage is not as bad as true blending, performance-wise.