Polycount vs Vertcount vs Textureres and Drawcalls
polycounter lvl 7
So recently I tried my hand at Arena Nets outdated environment art test to see how well I could do at modeling and texturing in an optimized manner. The way I saw it there were two approaches in regards to the texture layout and UV islands. This has been on my mind since execution and maybe can be put to rest :poly124:. For those that don't know the requirements were no more than 3,000 polygons and two 1024 maps (total resolution diffuse, spec and normal).
Method 1. Two texture atlases with many splits in the UVs (one atlas would have been optimal but ^2 limits prevented as such)
-Pros: two draw calls (at least two materials, maybe 6 draw calls with D/S/N?) [asking not telling]
-Cons: higher vertex count. potentially longer planning/execution workflow. someone might hate editing the mesh if passed on.
Method 2. Multiple tiling textures with potential atlas for misc./unique meshes (in this case ~5 tiling textures)
-Pros/Cons: pretty much the opposite of the above
I went with option 1 for the lower number of drawcalls thinking it would be more CPU friendly. But for the technically inclined, and maybe this is splitting hairs, are higher vert counts dangerous for processing? Maybe not single asset showcases, but open-world environments with models using method 1 where applicable. There would be an overall higher vert count and an overall lower total number of drawcalls. Or the exact opposite using method 2. Which method is, dare I say, "better"?
For visuals: http://www.allandunn.com/arena-net.html
Edit: spelling
Method 1. Two texture atlases with many splits in the UVs (one atlas would have been optimal but ^2 limits prevented as such)
-Pros: two draw calls (at least two materials, maybe 6 draw calls with D/S/N?) [asking not telling]
-Cons: higher vertex count. potentially longer planning/execution workflow. someone might hate editing the mesh if passed on.
Method 2. Multiple tiling textures with potential atlas for misc./unique meshes (in this case ~5 tiling textures)
-Pros/Cons: pretty much the opposite of the above
I went with option 1 for the lower number of drawcalls thinking it would be more CPU friendly. But for the technically inclined, and maybe this is splitting hairs, are higher vert counts dangerous for processing? Maybe not single asset showcases, but open-world environments with models using method 1 where applicable. There would be an overall higher vert count and an overall lower total number of drawcalls. Or the exact opposite using method 2. Which method is, dare I say, "better"?
For visuals: http://www.allandunn.com/arena-net.html
Edit: spelling
Replies
Today's hardware handles a lot more vertices with ease, but draw calls are still a bottleneck.
I think what ArenaNet is looking for (haven't seen the official specs) is a single texture atlas, one bitmap being the normal map, the other being the color map with specular in the alpha. So yeah, a lot of UV splits, but that's OK.
Method 2 makes sense if your set of smaller maps are being reused heavily across multiple meshes in the game. Also makes more sense with consoles that manage memory differently than PCs. IIRC, some consoles use memory slots of particular sizes, so smaller maps fit into those slots better than larger maps.
For a FPS game I would probably use method 2, as the resolution of a unique texture for that object probably won't hold up, unless it's crazily big. Alien Isolation used this workflow for many of their assets afaik.
Guild Wars, being a 3rdperson/birdeye perspective most of the time, lends itself to approach 1, as texel density is not a big issue at this distance to the camera.
To summarise:
Tiling Textures:
Pro:
-Higher Texel Density
-Potentially re-use textures for similar objects (set of houses, modular assets...)
-Pipeline/workflow is more flexible (easily swap tiling textures, create tilable libraries, etc)
-No need to create Highpoly, just create High quality tiling textures (might involve HPs >_>)
Contra:
-More Drawcalls (More texture loading)
-For Edges you need to use custon normals or bevels/support loops.
-No Unique detail in the textures
-No nice edges in normal
And Vice versa for the Unique Textures.
Ok awesome info - bare with me while I try to wrap my head around things.
When you say spec map into the alpha channel the file is still considered "one" texture just processed a little bit differently? I've seen methods using one of the RGB channels as the spec - the trade-off being grey values hard set by that channel. How that method might apply to different engines I have no idea, have only seen it used in Unreal with multiply and power nodes.
Method 2: Atlases with non-tiling/unique attributes could/should be shared if/when possible. Bonus points if the shared atlases are also instanced (trees). Even more bonus points if they're appropriately sized to fit memory slots (which they should be... otherwise, how might this get handled?). Gold stars for everyone if the atlas is shared, is instanced, fits the memory slot and can tile. All being said I should go ahead and use a smaller tiling texture for... whatever, a roof, it fits the memory slot dead on and otherwise couldn't be included into a larger one-axis tiling atlas. Did I get that right?
Method 1: Now only appropriate if it's entirely unique and never instanced OR is shared/instanced/tiles/fits memory slot (any combo as long as it fits memory). Also right?
I have the feeling then that PCs are (hate to use it) "better" suited for handling textures of all shapes and sizes? Maybe not so B/W but generally true?
Thanks for the response, the info provided here is a great help and definitely provides some technical insight!
Spec in alpha is sometimes called "channel packing", see http://wiki.polycount.com/wiki/ChannelPacking. Each of the four channels of a single bitmap could potentially contain a unique grayscale texture. Or you can pack a color texture into RGB and a grayscale one into alpha. It is considered one bitmap, because a "texture fetch" is the process of loading a bitmap into memory to use it in-game, and you load the whole bitmap to do this. If it was two or three or four separate bitmaps, each would have to be fetched.
Sharing can be done with tiled textures just the same as with atlases, no difference there. When assets share the same material, they can be batched into a draw call together. Batching is controlled by the game engine, and generally has some limits on how many vertices per element. Ask your programmer for details. Unity has some info here http://docs.unity3d.com/Manual/DrawCallBatching.html
Instancing is a similar thing, controlled by the game engine. A tool written by a programmer compares assets, and will only load one model, but re-use the same data to draw multiple copies. Trees for example. IIRC batching is better? Again ask your programmer.
Fitting stuff in memory slots... usually a Tech Artist or Lead Artist will tell the team what the general guidelines are. Texture budgets, etc. Usually though most artists don't have to worry about specifics. Too much information.
Methods 1 and 2 can be used together, they're not exclusive.
PCs are generally better, because the graphics cards are generally better, and you generally have more RAM. But the downside is the market is all over the place, people make their own PCs so you end up having to support all these different configurations. Also different operating systems. It's a bit of a mess. Consoles are kind of a mess too, (lots of versions within one platform: do they have the HDD or not, which rev, etc.) just less of a mess than PCs.
There's another way to tile atlases too, just requires more shader instructions (which can get expensive, depends). See the first tutorial here:
http://wiki.polycount.com/wiki/Texture_atlas
Def. agreed on the texel density aspect - method 1 involved adding some extra edge padding into the atlas to prevent mip seams and color bleeding (pain in the arse and reduced overall quality). Quite a lot of time can was spent planning just the grid so the textures could be evenly distributed... then modeling in relatively equal polygons to prevent stretching, THEN cutting all the UV shells into separate pieces.
Good point about the camera distance and actual genre of the game. I think that without really tight polycount and texture res budgets then tiling textures would be a no-brainer. Based on what I just briefly learned about texture sizes fitting memory slots, tiling textures are sounding even more appropriate.
Ahhhh ok, I was thinking memory slot was a term meaning somehow certain games were better suited to use an exact resolution for textures in regards to RAM. lol! So an art lead will just be like, "yea no 4096's and we're good." Or something along those lines.
Sooo then method 1 would be a really nice choice if parts of the atlas could be used on other models - like the roof, stone foundation, etc. cause they can also tile. It just means more vertices due to UV shell splitting which doesn't seem to be a problem. Thanks for the info!
Whoops didn't see this. Yea awesome tutorial for getting around landscape painting texture limits (16 textures per material in Unreal, or two 4x4 D/N atlases).