I would like to know which is the better solution for texturing an environment. Is it better to UV map the faces over a 2048 texture atlas or is it better to have multiple textures and a smaller 512 map for each type of texture. IE for your wood textures you would have a 512x512 picture and a separate 512x512 texture for metal,etc.
The dressing room example is why I am confused, since they used alot of draw calls by having many different textures over just one UV mapped texture. However I can say that because they used that method the textures looked better because they used more texture space.
To reduce draw calls, the easiest option is to use atlases that are assigned to a single material each. Obviously this is more work, though, and makes making changes hard, so you need to plan ahead. Another possibility is to create texture atlases at the end and to change the UV-mapping of your meshes at runtime using a script, though that’s work too (and increases load time). Also, since the screen is only 480x320, unless your player is going to see objects flat in their face for long periods of time, using 512x512 textures is probably a waste.
I suspect the purpose of the dressing room example is not to show optimization; it sounds like it’s not optimized in this fashion at all.
FYI, the max texture size on iPhone is 1024x1024 and not 2048x2048.
I have not developed for one, but I’m pretty sure the 3G does 2048, not that I am suggesting to use such large textures.
To the original poster, I think you are confused as to what a draw call is. It has nothing directly to do with UVs or textures. You can imagine it as increasing by one every time a mesh is sent to the renderer.
So, texture atlases help to reduce draw calls by allowing you us a single material for a complex mapping (since a materials are splitting the meshes into submeshes, more materials → more draw calls)
Sprite managers allow you to make many particles or sprites with just one mesh, thereby reducing the draw calls for all sprites to 1.
As to the size of your textures, this has to do with hardware requirements and memory. In general, the larger the texture the better because it is only loaded once and stays in memory, BUT this situation rarely occurs.
So, you have to know which textures are being swapped out more frequently (specific to a level maybe) and which are sticking around for longer (maybe a HUD texture) and separate your textures logically based on your needs.
You will have to start with a good idea of how to organize your textures, then you will have to tweak it in the optimization phase to get the most performance out of it.
On a side note, large textures are a pain in the ass to work with. The PSD source files are usually huge and full of crap by the end of development. You should take the time to either write a texture stitching tool (especially useful for sprites where the animators are creating them in overlapping layers, not in a sequence) or at least be disciplined enough to clean up your final source files before release.
On using the idea of a texture atlas, is it possible to have a square texture atlas with four quadrants, each of the quadrants being a tileable texture? (see attached image for what I mean)
The main goal would be to use a single texture atlas and a single lightmap on a material. This material could then be used to texture entire portions of a level efficiently. I have not been able to get the texture atlas to use a repeating portion of the texture though. It always uses the entire texture for tiling.
This is far to general to be useful. For instance, if you put all of your textures onto one sheet, but each is used in a different level, you will be occupying memory unnecessarily.
The problem you will find with tile-able textures on atlases is at the seams. Blending will pick up neighboring colors and compression can really screw up tiles as can texture reduction (mip-maps).
So, if you have tile-able textures on an atlas, you would be wise to leave padding around the borders. Depending on your settings, you can get away with a 1 pixel border, but 8 to 16 is not unheard of.
@1r0nM0nkey, how do you use a tileable texture atlas? Is this something that gets done in Unity or is there some way to do it using UV mapping from a modeling program (I haven’t been able to get it to work in Blender no matter what I try)?
You would have to separate the mesh and work with unique but overlapping UVs, as with tiled sprites (think super mario bros). Sprite Manager does a good job of this, but if you want isometric tiles with depth sorting, you would have to extend it.
If you mean wrapping UVs for only a portion of a texture around a mesh, that is tough. You would have to write custom code for that, and it probably wouldn’t be worth the gain of the texture atlas.
There might be some utility in modern modeling packages that allow you to define an area of a texture to be treated as if the area covers u/v (0…1), but I have never seen this.
edit: Of course, I should mention, you can simulate wrapping simply creating the appropriate UV mapping, but you would have to clamp the texture (or at least not us UVs outside of the area you are interested in) If your models are fairly simple, this might be an option. Sometimes brute force beats cleverness
That is exactly what I was looking for. The only way I can see doing this is to create a level with a whole bunch of squares tiled about to make corridors/rooms/scenery. That would make it easier (but still quite time consuming) to grab each face square and map it to a portion of a tile atlas. I suppose if I get desperate fpr performance it might be an option…
You are going to want to keep your mesh count as low as possible to reduce draw calls. I don’t know how your level geometry looks, but you might want to check out static dynamic mesh batching…
It is hard to help without knowing more about your scene, but the above links should get you headed in the right direction. For now, if you have a texture you want to wrap, you might want to keep it separate from the Atlas. If you end up with too many materials or not able to combine enough meshes, then you could optimize later, once you know more about your scene.
The problem is texture atlases and mesh stitching don’t play nice with wrapping.
edit:
I’m pretty sure you can position and rotate the sprites from SpriteManager in 3D space; you should take a look at it. Then you could create some co-routines to help you build tile sets and just place them to create your rooms. You will run into some sorting problems if you are not careful, but that is all pretty well documented in the SM forum thread.
