What's more efficient?
polycounter lvl 19
Well I have a question about textures. What uses more memory, having 4 separate 512 x 512 textures used in game or one 1024 x 1024 texture? A similar scenerio I'm wondering about is what is more efficient, to use 8 256 x 256 textures and one 512 x 512 or just three 512 x 512 textures. I thought using fewer larger textures is more efficient. The textures are going to be used for tanks that share parts, like the chassis. Oh this would be for use for a PC game. Thanks.
Alex
Alex
Replies
But it also depends on the layout of your scene, how often the texture is rendered. Everytime a texture needs to be rendered onto a surface, it needs to be sent to the texture cache. There's only so much room in there, so textures that aren't being used are generally tossed out to make room for new ones.
Tossing and loading textures takes time, it's generally slower to toss and load multiple smaller images than it is to load and keep a single larger one.
Some engines are designed to keep textures around in the cache longer than others, to try and predict if a texture will need to be used again soon. So asking about how it works in your case is a good idea. Plus you might get tips about what sizes will work well in your game.
http://www.ericchadwick.com/examples/provost/byf1.html
.. but generally you'll learn more by talking with your programmers.
so to be more precise one texture a "texture unit" normally your card can access like 4-16 textures at the same time, but not like per object, cause when you render a model that consists of multiple elements/objects the renderer has no idea what a object is, for it its just a big stream of vertices
so if you dont want 3 batches for your model but just one, use a single texture
minimizing batch count (or drawcalls) is a key to optimizing render engines
theoretically if your textures arent repeated, one can combine all 3 into a single texture (like horizontally aligned) and then modify texture coords of your source object in a fashion that their texcoords are shifted/scaled to use the new texture
the term for such packing is called "texture atlas"
you dont have to do square textures for PCs, I think only older consoles required square textures
so you could pack those 3 yourself in a row.
also some more there isnt a texture cache in hardware
there is a cache when sampling textures, ie when texels are read from the texture, but other than that textures are normally located on your graphics card and dont have to be "cached", since most people probably have 64 or more in their graphics card, most textures of your game will fit in (when compressed, and if your game doesnt have giant worlds)
if your card doesnt have enough, the driver has to copy texturedata from local RAM to VRAM, which will indeed be quite a speed hit. the engine coder can try to hide this a bit, especially needs to be done in giant worlds when you wander around and a lot of different textures are used...
so yeah it really depends a lot on the engine/type of game you work on, hope I could shed some light into the topic, I am working quite a bit on 3d engine code, but am no pro, anyway if there is more questions around how 3d realtime rendering engines work I'd love to help
Simple, really.
Sometimes the programmers will repack your textures anyway, and not tell you about it. I had that happen on a job once, noticed some weird resampling gumbo, had to squeeze it out of him but he admitted it in the end. He had an auto-atlas tool that would repack textures based on a batch analyzer. Changing the resampling filter was good enough for me.
Some very smart engine will take a lot of small textures of any size and stitch them together on the fly when the level is loaded, to be fed as large textures to the vid card.
Unless you have something like that, or your texture size is limited by some console hardware, or you're working with a crappy engine out of this world, or the whole game is supposed to use only 512 max res, 1 1024 texture will be always better then 4 512s.
Another question I have is, if different units share a texture that has different elements of the tanks will that cause the rendering to slow down or have to draw extra passes for the units? The image shows how the tanks will be put together in game. Each tank is made up of three separate elements chassis, turret, gun. It's similar to how quake 3 models are set up lower, upper, head. Right now the chassis will have it's own texture and I want to put two separate turrets, guns in one 512 by 512 texture to save on texture use. I want to use 1024 textures but that got shot down.
My concern right now is that by the time the project gets released the graphics will look so dated that people won't want to play it. Thanks for all the replies and links.
Alex
What argument did they use against a 1024x1024?
If in doubt remember that you can use a 256x512 or something like that as well but you're probably better off using one 512x512 for two turrets, allowing the parts to cross the square boundaries would also allow for more efficient UV mapping.
SF: What confuses me is that games like HL1 or DOAXBV (the latter I know because someone ripped a model from it into UT2003) use one texture per UV group. That's roughly twenty small textures per model. In HL1 all MP models are reUVed to use only one texture map so it's not an engine limitation. Why would you want to use one texture per UV group, isn't that horribly inefficient even if we ignore texture switching times?
and about graphics, I wouldnt worry so much, true graphics play a role, but you are not epic or blizzard who can afford army of artists and l33t engine coders. just get your game done and make it fairly nice. there is quite some good looking shareware games out there with dont use latest tech but at least look cool and run fine on nearly all hardware.
one can do a lot with non latest tech, by just using the old much more efficiently, WoW doesnt have ultra hipoly stuff and looks quit edgy, but good art compensates as their main goal is to target as many as possible and not just those with geforce6
about the tank, since all elements are moved independently, likely the coder will render them as 3 parts, unless some more high level optimizing is done and the individiual matrices for each parts are also processed in the vertex shader.
so if you have 1 tex for 2 turret types, you could render all those 2 turret types in one batch. however it needs some additional vertex shaders to do that, but rather simple. really depends what you guys want your target hardware to be, but I guess most people have at least vertex shader 1.0 these days.you can go further and pack all parts of the tank in a single tex and you can render like a lot more tanks in one batch...
the less states the engine has to "change" the better it is. (texture binds are among others state changes)
btw extra "passes" in rendering is meant to be rendering the same thing multiple times, like when blending layers on top. this however will not happen for your tanks, since they are solid and probably dont need tons of textures on top of each other.
I wouldnt worry so much about the tech, it mostly is the engine coders job to add the real high end performance
that said you can still help by limiting texture size and texture count, and count more than size.
always think of how the object is mostly on the screen, so yeah it might not look as hot when you are up close to the tank when using a bit less res, but assuming an RTS commanders' view, this is hardly the case.
then again you can always down sample and sharpen manually. ie make the high res and have it as "backup" or for special close ups.
so for batching its good to have big with many parts, as previous people mentioned
SF: What confuses me is that games like HL1 or DOAXBV (the latter I know because someone ripped a model from it into UT2003) use one texture per UV group. That's roughly twenty small textures per model. In HL1 all MP models are reUVed to use only one texture map so it's not an engine limitation. Why would you want to use one texture per UV group, isn't that horribly inefficient even if we ignore texture switching times?
[/ QUOTE ]
HL1... i wouldn't know what motivations for that they had 10 years ago. I'm not an archeologist but maybe it was better for cards without any hardware acceleration or memory... maybe they just weren't performance driven as people are now, dunno. I wouldn't really look at such old games, things have changed too much.
About the tanks... if that's the whole dilemma, i'd just go with whatever feels better for you. Keeping it all nicely in large sheets etc is something to keep in mind for the whole game.
If you now feel that in 1 situation it's better to use a texture more, who cares really, it's not gonna break anything. As long as you keep everything neatly clean you can allow yourself to go nuts here and there if you feel it makes a difference.
I pretty much use texture sheets and split parts i think i'll use in another models into other separate texture maps. Also, if i want a small part of a skin on another model i'll just have the whole skin for that other model loaded in memory too... Provided that other model is somewhere in the same level too, it's gonna be loaded to memory anyway.
Keep it all neat as a rule of thumb and then you can go wild here and there if your common sense thinks it's ok. You're not building rockets.
I doubt they had to worry much about performance and hitting memory limits with that game.