Home Technical Talk

UV mapping and performance

interpolator
Offline / Send Message
Zack Maxwell interpolator
I have a question about how certain UV mapping techniques can affect performance.
So first, as far as I know, only the parts of the texture that actually have UV mapping on them, and are therefore being rendered, will influence in-game performance. This would be the idea behind texture atlasing; having 4 models, for example, all using a single 4k texture, would have the same effect as those 4 models each using their own 2k texture, except that it reduces draw calls by sharing the same texture/material. Each individual model having so much unused space in the texture does not diminish performance.

Now with that in mind, how do mirrored UVs affect performance? For the longest time I assumed it would have a large improvement on performance by effectively cutting the texture resolution in half. But when thinking about the first thing I mentioned, it seems like the only actual improvement would be in reducing the file size of the textures, since the texture space is being rendered twice anyway. Which would also explain why mirrored UVs seem to be largely falling out of use.

To take that a step further, consider this. A tree model, with the leaves composed of many individual planes all sharing the same UV space. Would the in-game performance actually be the same if each individual plane had its own UV space inside the texture?

Replies

  • monster
    Offline / Send Message
    monster polycounter
    Assuming performance is defined as the render time per frame, the answers are:

    True, wasted texture space does not affect performance. But it wastes memory.
    Mirrored UVs have no affect on performance, they save memory.
    Yes, it would take the same amount of time to render a tree with stacked or offset UVs.

    In the case of the tree, it might be faster to let the game engine static batch all the planes. So instead of drawing verts for many quads, it draws one and duplicates the memory many times.

    I always think of performance as a triangle between processing, memory, and graphic fidelity. You drag one corner towards it's goal, and it pulls the other two corners away from theirs.

    [edit] Just to clarify. The triangle goals are Optimize CPU/GPU usage, Decrease RAM/VRAM footprint, and increasing graphic fidelity. [/edit]
  • Zack Maxwell
    Offline / Send Message
    Zack Maxwell interpolator
    I believe you're correct; by performance I just meant the potential effect on frame rates. But what do you mean by "memory"? The load it would place on RAM/VRAM?
    I seem to know a lot less about this subject than I thought. Does anyone know of good pages covering this in the wiki? I couldn't find them myself.
  • blankslatejoe
    Offline / Send Message
    blankslatejoe polycounter lvl 18
    Monster's "performance triangle" is a very good analogy.

    Here's a relevant example:  The way in which you unwrap a model can actually affect the final vertex count as well as UV splits will count as extra verts: in the case of all those tree leaves, the vert counts between your two methods would be the same, since you're just talking about shell stacking, but in something like a building, cutting up the mesh into tons of tiling UVs shells could actually add significant number of verts, which trades texture memory savings for a performance impact (usually worth it though).

    You could also approach your question more philosophically. Just because we have MORE texture memory available now doesn't mean you have unlimited. So, let's say that now you can use a 2048 for that tree instead of a 1024...do you give everything unique textures.... or still stack UVs and make the resolution of everything a little higher overall? Or perhaps a mix of both (2 or 3 variants of leaves on the same texture sheet, instead of one)? My vote would go for the third option, personally.


  • blankslatejoe
    Offline / Send Message
    blankslatejoe polycounter lvl 18
    "memory" can refer to the system RAM, but for us it's usually referring to the dedicated video memory on the graphics card. On consoles those two things are much less distinct, often shared for everything.

    The Xbox One, irrc, has 8gb of shared memory. Even having half that set aside for texture memory would still be a huge pool, but when you start throwing in a lot of 4096 textures (where a simple "set" of base/normal/packed metal+rough, all compressed can be ~50mb) you can see how it can get eaten away quickly. It's still a good idea to not be too wasteful with texture usage.

    If you run out of RAM usually bad things happen--the best of which is low mips are used, the worst of which (but surprisingly common) is a straight up out of memory crash.

  • Zack Maxwell
    Offline / Send Message
    Zack Maxwell interpolator
    Ah, thanks everyone. This has been very helpful.
  • RyanB
    Monster is right.  When making a game, you are making trade-offs and balancing. 

    You need to use tools and measure to find and fix problems efficiently.  Some things are obvious but sometimes the worst offenders are hidden.  There's good info available on how to use profilers, frame debuggers, etc.





  • beefaroni
    Offline / Send Message
    beefaroni sublime tool
    Reducing the file size of a texture is huge. That's less VRAM that has to be loaded on the GPU, and if you're using a streaming engine, that's more room for other textures to stream in at the same time / more quickly. In some cases, having a single 4k texture over (4) 2k textures can actually be worse for streaming since it's such a huge texture to stream in at once (literally 4x as large). There's also a limit to how much/how fast things can stream in, so having a lot of smaller textures that can stream in quickly as the player advances can be better than having textures pop-in as the streamer struggles to get the texture fully loaded. While it's not super current, there were a few areas in the original Gears of War where you could really see this happen.

    Going forward, let's say that you don't use 1 of your 4 models that are all on 1 4k texture. Well you're still paying for that 4k texture to be fully loaded/streamed on the GPU and you're not even seeing 1 of the objects. If they were split apart you could use 1 of the 4 somewhere else.

    Or, lets say that the textures mip out at a certain distance. Well now that 4k has to be loaded up at full res just for maybe 1 object close to the player while the other 3 maybe aren't super close to the player. It would be much more beneficial to split up the 4 objects onto (4) 2k textures instead. Or, if you're clever in where you mirror, maybe you can get each object on 1 2k/1k texture, saving even more VRAM for other objects in the scene. 

    Draw calls also factor in to this. It has been different from studio to studio in my experience so I'll just leave that part alone.

    Where did you see that mirrored UVs were falling out of use? 
Sign In or Register to comment.