Texture Size VS Count For Performance

[pardus3d]

Hi all,

In order to be most optimal for performance, I'm sure we want to use the least texture space possible for a model, and also the fewest amount of textures possible for the client to download and work with.

I am trying to best understand the balance between the two. For some totally arbitrary examples:

What would be better for performance, a single 1024x1024 texture or two 512x512 textures? One is twice the texture space and one is twice the files.

What about having a single 1024x1024 texture or three 512x512 textures? Then you have 3/4 the texture space but three times the files.

What about a single 1024x1024 texture vs three 512x512 textures and one 256x256? The second still uses a bit less texture space but now has 4 files instead of one.

My overall point is I'm really trying to get a sense of the balance between texture space and file count for performance.

Thanks!

[pardus3d]

Hi all,

In order to be most optimal for performance, I'm sure we want to use the least texture space possible for a model, and also the fewest amount of textures possible for the client to download and work with.

I am trying to best understand the balance between the two. For some totally arbitrary examples:

What would be better for performance, a single 1024x1024 texture or two 512x512 textures? One is twice the texture space and one is twice the files.

What about having a single 1024x1024 texture or three 512x512 textures? Then you have 3/4 the texture space but three times the files.

What about a single 1024x1024 texture vs three 512x512 textures and one 256x256? The second still uses a bit less texture space but now has 4 files instead of one.

My overall point is I'm really trying to get a sense of the balance between texture space and file count for performance.

Thanks!

[Rolig Loon]

This topic has probably come up at least once a year for the past 8 years that I have been in SL.  It's hard to improve on answers in previous threads.  Here are couple of the best .......

https://community.secondlife.com/t5/Building-and-Texturing-Forum/Texture-Optimization/m-p/700503

https://community.secondlife.com/t5/Building-and-Texturing-Forum/Texture-size-and-lag/m-p/2065601

[pardus3d]

Thanks for the reply I appreciate it. I had read that first thread you mentioned though I hadn't seen the second. I think they do still leave a little room for question on the balance point between size vs count.

I am under the impression that generally size trumps count but I wanted to get some other thoughts on it especailly in the more extreme cases like my third example. I am a web developer and in that arena we have a lot of the same trade offs between page weight vs number of request.

Thanks!

[arton Rotaru]

If it's two 512x512 it should be a 1024x512 but never a 1024x1024 instead.

To get the balance right is not so easy, I agree with that. What I try to do these days is, one texture per object, if possible. To keep the number of drawcalls as low as possible, which is IMO the biggest problem in SL. If you can combine multiple objects into a single mesh, and use one texture on all of them even better.

The size of the texture is determined roughly on a target texel density you want to maintain over your assets. For me this ranges somewhere between 50 and 100 pixels per foot. Depending on the object and how importend the texture detail has to be. With that in mind, I can rather easy determine which texture size it has to be to make the entire asset with one texture map, and maintain consistent texture quality.

Of course there are exeptions where the pendulum can swing to one side or the other.

So for me it's keeping the number of textures as low as possible, rather than using a bunch of smaller textures instead. Which would result in the same amount of memory consumption, but more drawcalls to be issued by the CPU. Which makes all the high end graphics cards rather useless in SL.

 

[Rolig Loon]

I'm not sure that you'll ever get an answer that is better than "It depends."  Unlike on-line games, SL is updated continuously.  The SL servers and individual viewers stream data back and forth all the time. Each viewer's input is making small changes that potentially affect the performance of every other viewer (Think, for example, of what happens in a crowded dance club as people come and go, change clothing, interact with scripted devices .... )  The result is that there are so many factors affecting performance, it's impossible to separate out any one of them.  That's especially true since each user has her/his own computer and Internet connection to deal with.  There may be theoretical ways to balance texture size and texture number for better performance, as Chosen Few suggested in his posts, but I suspect that any improvements will often be lost in the noise of other factors.

[ChinRey]

I can't really improve much on the previous replies. Both the number of pixels in each texture and the number of textures add to the overall render load and it's hard to say exactly how the balance between the two are. One 512x512 texture is certainly much faster to laod than one 1024x1024, two 512s are probably faster than one 1024, three 512s probably slower and four 512s certainly slower.

I do have an observation though: I ocne used an old 1024x2048 texture on one part of a build. It was jsut one texture among dozens of 512s and a few 1024s so if drawcall is as significant as arton seems to think, it shouldn't have made much difference. It did though, that texture took ages to render every time I got anywhere near that part of my sim. In the end I downloaded it and scaled it down to a more sensible 512x512 (with no noticeable quality loss).

Personally I don't think you should be afraid of using high resolution textures when they are needed. Yes, they do cause quite a bit of extra laf but sometimes it's worth it for the extra quality you get when it eventually renders. It's abusing high resolution textures that is the big problem. When builders use 1024 textures on tiny pieces of jewelry and such, when texture makers fakes high resolution textures by simply scaling up or repeating a lower res one... In other words, when you add lag and get nothing in return for it.

---

Rolig Loon wrote:

I'm not sure that you'll ever get an answer that is better than "It depends."  Unlike on-line games, SL is updated continuously.

---

That's true. And right now the most effective way to fight texture lag is, strangely enough, to close all group chats as quickly as possible. When a group chat pops up, your computer starts loading the full size profile pics of every single person logged on to that chat. Those pictures add up to far more graphics than even the busiest in-world scene and to make matters worse, they have higher cache priority than the textures you actually see around you.

[Pamela Galli]

---

ChinRey wrote:

I can't really improve much on the previous replies. Both the number of pixels in each texture and the number of textures add to the overall render load and it's hard to say exactly how the balance between the two are. One 512x512 texture is certainly much faster to laod than one 1024x1024, two 512s are probably faster than one 1024, three 512s probably slower and four 512s certainly slower.

I do have an observation though: I ocne used an old 1024x2048 texture on one part of a build. It was jsut one texture among dozens of 512s and a few 1024s so if drawcall is as significant as arton seems to think, it shouldn't have made much difference. It did though, that texture took ages to render every time I got anywhere near that part of my sim. In the end I downloaded it and scaled it down to a more sensible 512x512 (with no noticeable quality loss).

Personally I don't think you should be afraid of using high resolution textures when they are needed. Yes, they do cause quite a bit of extra laf but sometimes it's worth it for the extra quality you get when it eventually renders. It's

abusing

high resolution textures that is the big problem. When builders use 1024 textures on tiny pieces of jewelry and such, when texture makers fakes high resolution textures by simply scaling up or repeating a lower res one... In other words, when you add lag and get nothing in return for it.

---

Rolig Loon wrote:

I'm not sure that you'll ever get an answer that is better than "It depends."  Unlike on-line games, SL is updated continuously.

---

That's true. And right now the most effective way to fight texture lag is, strangely enough, to close all group chats as quickly as possible. When a group chat pops up, your computer starts loading the full size profile pics of every single person logged on to that chat.

Those pictures add up to far more graphics than even the busiest in-world scene and to make matters worse, they have higher cache priority than the textures you actually see around you.

---

Wow that is news to me!  I am going to pass this tip along to my group.

[arton Rotaru]

---

ChinRey wrote:

 

I do have an observation though: I ocne used an old 1024x2048 texture on one part of a build. It was jsut one texture among dozens of 512s and a few 1024s so if drawcall is as significant as arton seems to think, it shouldn't have made much difference. It did though, that texture took ages to render every time I got anywhere near that part of my sim. In the end I downloaded it and scaled it down to a more sensible 512x512 (with no noticeable quality loss).

 

---

Well, if that one texture was just one texture among all the others, at least this is how I read your post, it certainly doesn't make a difference in draw calls. It's just one draw call, be it a 2048 or be it a 256. And certainly, a larger texture will take longer to download. But it should roughly take the same time to fully download a 1024, or four 512's. But if you have cached everything, download speed shouldn't matter much anymore. This is when draw calls come into play. If you have thousands of unique assets, and with probably multiple textures on each, you'll have a problem even if you have cached everything already.

If this 1024x2048 would replace eight 512's on a single mesh asset, you have definitely a win in draw calls/state change.

Also, it's not this 8 textures more or less in a scene, but doing this on every asset, things add up quickly indeed. It's why games make use of texture atlases. Sure, you don't have to download these atlases when playing a AAA games. That's why we do have to make compromises, and have to live with slower performance in SL. Be it streaming, memory, or draw calls.

It will never be perfect.

I may should add, lag to me is slowdowns in FPS, I don't worry much about download lag. This takes some time anyway, no matter how small, or as few textures are in use. But once I have cached the sim, all is fine.

[ChinRey]

---

arton Rotaru wrote:

Well, if that one texture was just one texture among all the others, at least this is how I read your post...

---

That's right. That texture was noticeably slower to render than all th other textures in the scene. I used it at my store for a cobblestone road in front of my victorian townhouses. I only have two such houses for sale at the moment and they're both low lag so without that texture there's hardly any render load in that section at all. Even so, that texture rendered noticeably slower than the entire scenes of much "busier" places in my sims.

That was a texture larger than 1024x1024 though. They're not really supported by SL and you can't even upload them anymore so it's quite possible some special conditions apply to them.

[pardus3d]

Thanks for all the replies they have been very informative. I also had a long talk with someone from the Maya users for SL group and we came to pretty much the same conclusions that seem to be the main themes here.

In that case, it would take some trickery to get anything outside of a square texture map (like a 1024x512). I had thought of it as one way to keep texture space down to a bare minimum but found that it's generally not done that way.

My prior 3D experience has been with high detail still renders or pre-rendered animations. This is my first attempt and creating things for an engine where performance matters so I wanted to do it right and be considerate of everyone's performance.

[Rolig Loon]

On a related side issue ......   When you're making decisions about how big to make a texture for SL, it may help to ask yourself how long the average user is likely to pay attention to your work.  If you are making a sign with a lot of information on it, it may be worth the effort to create a 1024 x 1024 texture, despite the fact that some users may experience a bit of lag from it.  If you are creating a texture for a rock, however, chances are good that most users won't do much more than glance at it, so you don't need high resolution.  A 256 x 256 texture will do.  Creators will always be more attentive to details in their work than anyone else, so it's difficult to admit that sometimes less is more.

[markkemp]

I've written some guides here:

http://www.downloadtexture.com/using-textures-efficiently/

http://www.downloadtexture.com/how-to-use-materials-efficiently/