Texture size vs. quantity
polycounter lvl 18
I've searched but couldn't find a discussion on what kind of performance impact textures have. Is it better to have fewer, larger textures or many smaller ones?
It depends of course, but if that's your best answer, could you please specify what you know about the platform you're working on? e.g. I've read here that the ps2 likes lots of little textures (as in 256 and 128s). What about the 360 or ps3? Or specify a game engine and what it prefers, if you could please.
Even more specifically, for large models with a lot of parts (big complicated machinery for example, or a complex building), is it generally better to unwrap and texture each of the parts? Or put them all on one big sheet?
Thanks for your time
It depends of course, but if that's your best answer, could you please specify what you know about the platform you're working on? e.g. I've read here that the ps2 likes lots of little textures (as in 256 and 128s). What about the 360 or ps3? Or specify a game engine and what it prefers, if you could please.
Even more specifically, for large models with a lot of parts (big complicated machinery for example, or a complex building), is it generally better to unwrap and texture each of the parts? Or put them all on one big sheet?
Thanks for your time
Replies
However, smaller more generic textures for environments means you can share textures between lots of objects (buildings), so they get kept in memory for longer anyway.
A street of shops example:
Common bricks, more bricks, concrete, road, pavement, generic metal for pipes etc. These are used on many of the buildings and the street itself.
Unique single textures per building (brick, plaster). These are probably used in other areas of the game, just not in the immediate area.
Unique detail sheet for some buildings/shops - branding, window display, signs.
So it sounds like texture calls are more precious than the memory they use up. In other words, fewer and bigger is better for most modern platforms?
I think an important step to take is to unwrap the model so each piece gets maximum detail and is EASY to paint (very few inverted pieces or weird angles). Be it one large UV space or several smaller it doesn't matter, whatever is easiest to paint on. I call this a "Master UV layout". Later you can go in and re-arrange the UV pieces to a new UV channel and bake/render to texture the Master UV channel to the new UV layout.
That way you're never far away from delivering what is needed and you only rearrange the pieces once. It beats the hell out of rearranging things in Max, then trying to rotate and scale everything in PhotoShop.
This trick also works well when you're working on multi-platform titles, or just want to go from 2 sheets to 1 or vice versa.
the amount of materials and the amount of batches/draw calls that will result out of them does ... the fewer draw calls the better !
so try to use as few materials as you possibly can without fucking up your own work flow too much.
in a regular engine you will get an extra draw call for every new texture you use. (not as in texture combinations diffuse/spec... for a material, but say your object uses 4 diffuse textures)
Likewise if you have an object that breaks into smaller pieces like a robot that is destroyed and its arms ad legs fly off leaving the torso sitting in the ground for the rest of the game, it might be a good move to put the arms and legs on a separate sheet so those sheets are removed from memory when it is destroyed.
[/ QUOTE ]
Actually that probably wouldn't matter, unless there was a specific technical reason for doing so. Firstly 99.9% of games would remove the torso once you've moved away anyway, and secondly, if it's supposed to remain there, like it's the remains of a boss, then the area will hav ebeen designed with the memory footprint of the entire robot in mind anyway - you don't need to free any memory up by removing things unless there's a specific reason to do so (like right after you destroy it a team of 7 guys turn up to attack you, after being spooled into memory) - and if that's the case you're going to be informed by whoever's responsible for the more technical aspects of your work anyway.
The specific technical reasons I was thinking of where:
- RTS's units that can be scavenged (so you can have many objects on the screen staying for extended periods of time)
- Objects/structures that have large additions that appear/disappear when it is up/downgraded or disabled.
- Destructible enviromental objects like a tanker fuel truck after the tanker explodes. If the truck always stays and the tanker always is reduced to an axle. Put the Axle on the truck texture, and leaving the tanker on its own.
Like I said its all more memory management and might not gain you an advantage. But in some cases it might be one more trick you can pull out of your bag that lets the unit cap be set to 300 instead of 175.
I think the important part of my post was to remember you can keep your UV's pretty fluid and adjust them to whatever the technical demands are. Which takes the stress out of "oh crap I unwrapped it wrong". It should only take as long as to rearrange the pieces in max and render out a new map(s). Instead of having to re-unwrap the traditional way costing you several hours if not an entire day.
Also if you create a master UV channel that is easy to paint on you'll save yourself some time.
Is there a way for me to do with with some other program like HeadusUV or modo? Max is crashing a lot on my laptop, and I can't afford a new computer that would handle it yet
the size and amount of textures doesn't really effect performance.
[/ QUOTE ]
Up until the scene requests reads from a texture set that doesn't fit in vram, in which case you will fall off a performance cliff.
Considering vram varies from 768 Mb down to 128 or lower, texture memory use is definitely an issue.