Drawcall efficient Z-sorting with multiple atlases

[ivomarel]

Dear all,

Currently I am working on an mobile isometric strategy game, with multiple animated buildings. Since there are many buildings and they are quite detailed (high resolution) I can't fit all buildings in one atlas. In fact, I need 3 atlases (2048*2048) for all buildings. However, the user can move the buildings around and put them behind and in front of other buildings. This is easily done by z-sorting, but by having multiple atlases z-sorting, the drawcalls increase dramatically. Since it's a mobile game, I'm trying to decrease the number of drawcalls to 25, but now, every overlapping building (of a different atlas) costs one extra drawcall.

Does anyone have a smart solution to this problem? I'd get a 4096*4096 atlas, but I'd like an Ultra HD atlas as well, which would then require a 8192*8192 atlas and Unity doesn't seem to accept that.

Any help is greatly appreciated!

Cheers,

Ivo

[unikronsoftware]

Are they pixel perfect, and do they have hard pixel edges? If so you can use alpha test and not require sorting at all.
This is one of the reasons it isn't recommended to use atlas spanning - it makes draw call management close to impossible in these kinds of situations.

The final option is to perform a screen area based sort every frame based on the camera and what it can see. This can be tricky but can seriously reduce draw calls when there is no overlap. But... in your case, with buildings in particular, I guess there is a fair bit of overlap?

[ivomarel]

Hey there!

Thanks for your reply.

The problem is that I use camera zooming, which makes it impossible to have the buildings as pixelperfect (right?). Actually, I am not familiar with alpha testing, but I'll look into it.

Another solution I came up with, would just be to separate every building in their own atlas. This adds way more drawcalls, but might be lighter because the atlases sent to the GPU are a lot smaller. Any thoughts on that perhaps?

I'll keep on testing

[unikronsoftware]

Hi,

Splitting up like that won't really help.
The issue is draw calls increase CPU overhead. Splitting up into smaller atlases will have better guarantees on draw call order, but won't reduce them. You won't really save much doing that.