Author Topic: Non-atlased bitmaps / Rendering order  (Read 3443 times)

AmpliMath

  • Guest
Non-atlased bitmaps / Rendering order
« on: April 01, 2013, 05:36:10 AM »
Hi all,

I am still new to NGUI, but slowly getting there. So thanks in advance for you patience!

I was wondering on how the rendering order is performed in panels. If I understand well what I read, widgets can be properly sorted using the Depth, provided they are in the same panel. My problem is that in some situations, the UIPanel can hold a non-atlased UITexture in between the other widgets, and there is no clean way to render properly.

Consider the following example, where my panel is made of the following elements, listed in the desired rendering order (from my standpoint)

MyPanel (UIPanel)
  Title (UILabel / using Atlas1)
  SpriteBackground (UISprite using Atlas1)
  Icon (UITexture standalone Texture)
  SpriteOverlay (UISprite using Atlas1)

From what I could understand of the code, this would mean the following in terms of draw calls, if "Icon" has a closer Z value than the other objects:
  Drawcall #1 : title / SpriteBackgroud / SpriteOverlay
  Drawcall #2 : Icon

Now suppose SpriteBackground, Icon, and SpriteOverlay all are semi-transparent: there is no clean way to render this in the correct order, no matter what you set for the Z value. I suppose one might argue that I could atlas Icon. The problem is that when you have 600 icon possibilities, it cannot all fit in the atlas.

In the attached image, you can see a complex screen showing a list of star system. Most of the widgets in each line use atlased textures, but the construction icons and hero portraits cannot fit in the atlas (too fat, too many). The problem is that I am supposed to draw a semi-transparent selection overlay on top of the selected line, so Z sorting will not be possible.

So I am wondering how you would solve this kind of issue...

Would it be possible to allow the UIPanel to break down the rendering even more? In the first example, this would result in:
Drawcall #1 : title / SpriteBackgroud
Drawcall #2 : Icon
Drawcall #3 : SpriteOverlay

Obviously this would increase the number of drawcalls, but at least the correct rendering order would be possible, and the Depth value would be relevant for all widgets inside the panel, even those not atlased. I also understand that in some cases (like in my attached example), it could break the rendering in many draw calls (each time you swap from atlased to non-atlased), but if you know it and that is the only viable solution, so be it. Has this option been considered?

The other solution would be to dynamically integrate the texture to the atlas, when it is needed. In the screen example, I would for instance reserve 20 technology icons locations in the atlas (to preserve their texture coordinates), and simply replace the texture content with the currently needed icons. Does it make sense? It can be pretty hard to pre-determine how many dynamic icons would be needed by the game, depanding on how many elements the game resolution will change...

Thanks for your input.

AmpliMath
 

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Non-atlased bitmaps / Rendering order
« Reply #1 on: April 01, 2013, 06:02:13 AM »
Easiest thing to do would be to create an extra panel for your overlays, thus separating the batching. If you search the forum for the keyword "sandwich" you will find a more detailed explanation.

Nicki

  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 33
  • -Receive: 141
  • Posts: 1,768
    • View Profile
Re: Non-atlased bitmaps / Rendering order
« Reply #2 on: April 01, 2013, 07:27:15 AM »
Like ArenMook says, split it into multiple UIPanels, that will give you the desired effect. UIPanels should be ordered by z-position - closer to the camera gets rendered on top.

Alternatively, you can also create multiple cameras and have multiple GUI layers - this is an advantage if you need some things to be orthographic and others to be perspective - if you don't need that, though, just go with panels. ;)