3d text burry

[DirtyHippy]

For a while now I have used 3d nameplates, and they work fine, and aesthetically look the way I want, but the text just looks bad.  I also support them as 2d nameplates - clearly they looked super crisp, but a lack of depth information and some other things make me dislike them a bit.

Is there any way to get the text crisper or is this just a limitation of rendering the text in 3d space?

[DirtyHippy]

So mucking around today I have been able to get the 2d nameplates in a place where I am happy with them.

So in addition to the first question (which I am still curious about), the second question now is: how expensive is changing panel depths?  I.e. for 2d nameplates, I am dynamically changing nameplate panel depths based on the distance from the camera (where each nameplate has its own panel).  While I would like to avoid having panels on each one, I figure that has to be faster than having a single panel and changing a ton of widget depths (and a lot easier).

[ArenMook]

Changing panel depths is effectively free. Changing widget depth may be expensive, but not panel depths. That said, a panel per name tag means a lot of extra draw calls. I'd suggest try using one panel with multiple labels underneath. You can adjust the labels' depths. Since the names move around all the time already anyway, tossing in a depth change in there won't have any effect on performance.

3D elements will always be less crisp than 2D -- that's just how texture filtering works. Keep in mind you can always scale labels to fake 3D, not just adjust their depths.

[DirtyHippy]

I have a number of widgets on my nameplates - three labels, three progress bars, labels for floating text, icons, etc.  This is part of the reason why I thought a panel per nameplate might be better.  I was under the impression that changing a widget would invalidate the panel, so if I had 30 nameplates under one panel, a single (health) progress bar changing would require the panel (and all 30 namepletes) to re-process.  I figured that at some point the drawcall cost would be outweighed by NGUI CPU cost for the invalidation.

In any event, good to know.  Thanks!