-1

Many sprites/textures with a high resolution have partially transparent pixels arounds their edge to make their edges smoother (antialiasing basically). When rendering these it seems to me that you have to do the same as with any other sprites containing partially transparent pixel, which is to render them from back to front. That is if you want proper blending, of course.

But is there really no way to render these sprites with these tiny edges of partially transparency with some order independent method?

I'm attempting to do this, because I want to store a large number of static sprites in a seperate buffer from my dynamic sprites, such that I don't have to reupload the data every frame. However, with these partially transparent static sprites, I have to sort them together with all my other dynamic transparent sprites every frame. Of course, this is only a problem if my static sprites can be in between my dynamic sprites depth wise, but that is unfortunately what I want.

genpfault
  • 51,148
  • 11
  • 85
  • 139
maltebp
  • 11
  • 1
  • 1
  • 1
    Since you are using sprites, I am assuming that you are implementing a 2D game or using 2D sprites to simulate a 3D effect in a 2D world. In either case, depth sorting shouldn't be the problem. – Rabbid76 Jun 03 '21 at 19:52
  • Indeed, I am implementing a 2D game :-) I suppose you mean that the depth sorting is not a performance problem? I think you are probably right. But I am also asking this question because I expected there to be a simpler way around this which I had just missed. – maltebp Jun 04 '21 at 06:51

1 Answers1

1

There is unfortunately no way of getting around depth sorting. Consider the case where there is a completely solid pixel behind a partially-transparent one. You have to to draw the transparent one last, otherwise you lose all the information from it.

Now consider how the situation changes as the completely solid pixel becomes very slightly transparent. It doesn't really change things; the solid pixel would still blow away information if written over the partially-transparent one. You could do some sort of calculation to apply an opacity and color tint to the solid pixel to allow you to draw it after the fact, but the calculation is equivalent to just drawing all the pixels in depth order.

So you really have to draw everything in depth order.

If the sort every frame is a problem, maybe you could optimize things by breaking stuff down into "background" and "foreground" layers? (or even three or more layers). Draw the background dynamics on top of the background statics and then draw the foreground.

Or perhaps you could keep all your sprites sorted using a heap?

jnnnnn
  • 3,889
  • 32
  • 37
  • What about [Order-independent transparency](https://en.wikipedia.org/wiki/Order-independent_transparency). – Rabbid76 Jun 03 '21 at 19:55
  • 1
    It looks like OIT is the equivalent to the hypothetical "calculation" -- it's still sorting, but just offloaded somewhere else. The approximation stuff sounds interesting though. – jnnnnn Jun 03 '21 at 19:58
  • There are algorithms that work without sorting. The color channels are weighted according to the depth and alpha channel. I think the following paper describes such an algorithm: [Moment-Based Order-Independent Transparency](https://momentsingraphics.de/I3D2018.html). – Rabbid76 Jun 03 '21 at 20:03
  • I have been fiddling with OIT previously for another project, and I found it complicated enough to seek another solution for this project. However, I have just stumpled upon [Alpha to coverage](https://stackoverflow.com/questions/23280692/opengl-es2-alpha-test-problems) as mentioned in this post, and I think this may be perfect. – maltebp Jun 03 '21 at 20:17