Less Vertices or Smaller Textures???

DriveJunky95

I was talking with a friend about how awesome texture atlasing was for using a handful of smaller tiling textures, but then he mentioned that would mean a higher vertex count. Using a smaller texture is more cpu-efficient, but now I'm wondering if the smaller textures are worth their weight in vertices - so to speak. Might anyone have any info on how a [for example] somewhat dense vertex environment might really effect gameplay/framerate/that sort of thing? Is this something that needs to be considered while modeling? Orrrr is it that in todays age our game engines and cpus can handle it? Any insight would be awesome!

Meloncov

It obviously depends on just how much denser the mesh is, and what engine you're using, but generally speaking modern games tend to run up against the limit of texture sizes rather than poly count.

Eric Chadwick

Mobile is one place where vert count is still a big issue.

But like any perf issue, it's always relative to your specific situation. Best to run perf tests to see what your bottlenecks are.

sprunghunt

The PS3 is one platform that doesn't like lots of small polygons. It does depend on your engine though. Splitting up models into separate textures can add drawcalls and that can be much worse than a few extra textures.

warby

wait why does using smaller textures mean higher vertex count ?

you mean because it needs to get uv mapped differently and have more cuts/ more vertex splits ?!

Kurt Russell Fan Club

warby: I think his friend means that if you're using texture atlassing as well as wanting tiling textures, the only way to achieve it is by using more polygons. Imagine a quad that had a texture tiled in 4x2 grid. To do that with an atlassed texture, you'd need to cut the quad into 8 separate quads and UV each of the tiles individually.

Next-gen shouldn't have this issue because shaders support texture arrays, and they're much better than texture atlasses.

DriveJunky95

Hey everyone, thanks for the responses - there's a wide-range of insight here that is more than helpful! SO, in summary it's looking like texture resolution and the number of drawcalls should be considered when modeling while vertex count is something to be considered for hero assets and mobile games. I did not know that games are hitting their texture resolution limits before their polygon limits - that is good to know!

All things considered, I've thought of another scenario that I'm not sure the answer of and input would be awesome. I'm currently working on a game at my college and I'm in charge of the environment. Right now there are multiple models that all share the same texture (me thinking this would be more convenient for our designers). The texture is not tiling but rather a unique UV layout with multiple models on it.

In essence, this is my dilemma:

1 Object ---> 1 texture (potentially smaller texture based on scale of model)
3 Objects --> 1 texture (larger texture to provide enough resolution for all objects)

So, each object will have one drawcall while in-game. BUT, now I'm thinking it doesn't make sense to have an object use PART of a larger texture because it will be referencing a LARGER texture (while it could have a smaller, unique texture).

So which is best? An entire scene that is made up of one large texture OR a scene that is made of a bunch of smaller textures? Does using one larger texture have any "cpu/engine/programming" benefits that outweigh a scene that references a bunch of textures?

EDIT: I suppose it doesn't hurt to have a model share a texture that would be the same resolution were it not sharing a texture. However, my models vary in scale and could use a 512 or a 256 instead of a 1024 that it currently shares.

Kurt Russell Fan Club

If you have many objects in your environment use one texture, you'll end up with good speed results. There are two good reasons that engines often support one/more of: batching and instancing.


State changes are what happens when you change which shader you're using or which texture the shader uses, or a bunch of other things. State changes suck up your performance, because they basically mean you need to use more than one draw call.

But what this means is that if you're drawing multiple models using the same state (the same textures and shaders) then they can be sent to the GPU in a single batch. Meaning one draw call... assuming your programmers write it like that!


Instancing is a way of drawing the one mesh multiple times. Like single draw calls above, it's only possible if you don't change state (so use the same mesh and the same texture and the same shader and the same transparency etc.) but has the benefit that you don't need to send much data to the GPU per object -- just the position/orientation and any per-instance values like colour or light map UV offset.

Instancing is perfect for when you've got the same model (e.g. a tree) and you want to draw it all over the place with the same texture(s) and shader.

If you want the same tree model drawn with multiple different textures, it's actually better for you to have all the tree textures in one big texture sheet (or texture array, if you're using next gen engine) and then each tree instance will pick from one of the trees.


You should talk to the programmers/designers on the team to see what the engine supports. Some engines just support instancing (so reusing the same mesh with the same texture will be fastest) and others have dynamic batching, so any time you reuse the same shader/textures (regardless of the mesh) it'll be faster.

Bartalon

^ Awesome bit of info, thanks for sharing Kurt Russell Fan Club

warby

yeah what "kurt russel fan club" said !

always roll with the solution that has the fewest separate objects/materials (drawcalls)

that is almost always achieved with fewer larger textures !