Four 512x512 or one 1024x1024 texture?

An example.

Say you had a cube and wanted a nice detailed texture on each face.

Is it faster (beter ptractice) to create 4 seperate image files of 512x512, upload them seperatly and place one of each of the 4 faces of your cube

Or would it be better (and if so, or not I'd like to know why) to create ONE image (say in photoshop) that had all your seperate 512x512 pictures in a grid. Upload that one 1024x1024 texture then use the texture offset tool to make only the part you want appear on each of your 4 cube faces?

Ok, you will save L$30 in the uploading process

But what are the technical benefits or down sides to doing this?

Just wondering

This interesting question seems to be asked about once every three or four months. Search the archives and you'll find a range of speculation and logic. Try this thread, for example... /109/33/294395/1.html.

EDIT: Silly. I got interrupted before typing the bottom line. Uploading a single 1024x1024 texture that contains a mosaic of four 512 x 512 textures makes sense if you are always going to put all four textures on the same object. It saves L$30, of course, but more importantly, it saves three extra uploads and it means that the viewer's system will have to rez only one image instead of four. It's a marginal savings, but probably worth doing. If you are ever going to be using the four components separately, though, you will be putting unnecessary demands on viewers who STILL have to rez the full 1024x1024 to see any part of it.

Most of the slowdown in modern real time 3d is usually due to texture rendering and shader processing. Using a larger image instead of 4 smaller images has some benefits. From a hardware point of view your video card only has to make one texture call and address one image location in the video cache. It's one resource pull down instead of 4 from the SL servers and 3 less images the client has to cache and manage. Of course just putting 4 512s on one 1024 page isn't going to net visible speed gains in most cases. Especially in SL where cubes with unique textures on each side are one of the basic 3d building, er, blocks. But at least YOUR build will be optimized.

I have heard that LL have tweaked it so that 64 and 512 sized images have download priority so that sculpties and avatar textures will appear sooner. So you might want to ask yourself if you could get away with using 256 instead of 512s. If you combine 4 256 onto one 512 you are gaining some speed, smaller footprint, and could actually see a visible DL time improvement. But with a 1024 it might take longer to see, not just because its larger, but because SL is letting 512s to the head of the line. I don't remember seeing official documentation on this though (as if!), so it could be a SL urban legend.

Also, a cube has 6 sides

Thanks for you replies and links to similar questions.

Perhaps I shall do a test myself, but as you say it may come down to the way Linden decide to order things than any technical reason.

Oh, and I know a cube had 6 sides

I have a situation like this in my shop. I prefer to use a 1024 x 1024 texture for my textures on my vendors, so they all rez at nearly the same time. (4 vendor pictures per texture)

/me was wondering about this lately..

I remember from the ARC blog post.. http://blog.secondlife.com/2008/05/01/who-me-yes-you-couldnt-be-then-who-introducing-avatar-rendering-cost/


Does this mean that there's more internal goodness to sharing one big texture than is obvious?

That's what it sounds like, in a sort of "save the whales" way. By reducing the number of separate calls to the GPU, you not only make each individual call more efficient but you also minimize overall stress on the system, improving overall performance. I think that what it says anyway.

A sticky from Ramzi or Pastrami or one of them, along with some of our resident uberbuilders, would be really nice.

That's what it means. That's what I was trying to get at in my previous post. For each texture surface (or per pixel in the case of some shaders) the video card needs to determine if it already has that map (or maps if the surface is using bump/normal, specular etc. must check for each one) loaded in memory or if it needs spend a cycle to retrieve it so it can render it in a later processing cycle.

So say you have a cube and you can see 5 sides, that's 5 possible texture memory calls if you use unique maps and they are not in memory (10 if there is a unique bump map as well as unique diffuse, and so on as you add layers of map complexity). Making a larger map and putting portions of it on each side cuts down on the amount of calls as it only needs to poll for one map instead of 5. This all happens PER FRAME.

This is why textures are the bottleneck in realtime 3d.

reading this thread got me to thinking I should do it this way too

I used to use 1024 single vendor pics (yes I did not know it was better to use 512 size)

so when I learned 512 wads better I switched to that but still a single pic per vendor

now I am learning that I can put 4 pics on a 1024 so thus covering 4 sales boxes in one texture, less loading time over all one would think

and being I am planning to redo a lot of my ads as I redo a lot of item permissions, this info could not have come at a better time

I will be watching this thread though, hoping that chosen puts in some info, as he seems to have the answer for just about everything

I've tried to do this - put a bunch of textures into a single 1024x1024, 24-bit PNG.

When I try to use this new ubertexture, I get color distortion at what looks like the very right edge and bottom of the uploaded texture - maybe just one pixels worth. I've looked very, very closely at the original and do not see it there.

Any tips for avoiding this?

Fudge your repeats just a bit smaller.

SL is terrible about that. No matter how carefully you slice a texture, or how accurately you specify repeats and offsets, it often 'borrows' one pixel from the area beyond the cut.

What is really annoying is that even on a 1.000 repeat both ways, it tries to 'borrow' a pixel from the opposite edge!.

TY! That seems to have done it..

How annoying.