Texture Optimization Question, SCiENCE FiCTION region.

G'day Fellow Residents,

Here on the "Science Fiction" SIM, we're seeking to optimize our region quite a bit.

Regarding "Texture Optimization", I have noticed that a default BOX PRIM object, which is say colored in just 1-color (e.g. GREEN) from the Linden color palette will in fact be covered by 32x32 green texture images.

For Example:

Select an OBJECT and hold down: "Ctrl, Shift, Alt + T" to see the texture information on an object.

Choosing standard colors from the Linden Color Palette appears to apply 32x32 textures on a basic Cube with the wood texture removed.

Texture info for: Object
32x32 opaque on face 0 1 2 3 4 5


Here's My Question:

On a simple 1-color, prim object to be positioned somewhere on a sim, is there any marginal performance benefit or texture optimization gain, by applying 16x16 basic color textures to an object created from uploaded "Lose-less Compression PNG images @ 16x16 pixels", instead of using the default 32x32 textures on Linden region servers?

Sure this means applying new textures on all sides of every opaque object, but if this yields:

Texture info for: Object
16x16 opaque on face 0 1 2 3 4 5

...surely, it's gotta add up to some savings?


Look forward to hearing people's thoughts and answers


Sincerely,


DMC Zsigmond

Estate Owner
SCiENCE FiCTION
http://www.sciencefiction.info

I've always thought that textures were cached, so no, the savings don't add up. They only need to be downloaded once. And I suspect that the difference in size between the two isn't all that great, because of the overhead.

I would think the textures would load faster so that would be an apparent gain in performance for anyone coming to the sim. And since it's half in pixel size the servers would only half to send half the texture data to each viewer.............that's a 50% decrease in texture transfering between the servers and anyone in the sim. So, my guess is, yes, it would improve performance. But, would it be noticable? I don't know, 32 by 32 is pretty small too.

This really should be in the texturing forum, not here. It's quite disturbing how Resident Answers has been treated as such a free-for-all over the past few weeks. The forums are categorized for good reason. Please, everyone, post appropriate topics in appropriate places.

That said, let's talk about your question(s), DMC.



The answer is yes, there will be a small benefit from replacing the default blank texture with your own smaller one. If you had gone to the texturing forum instead of here, you would have seen a sticky at the top, all about texture sizes and how various choices impact texture memory. In it, you would have found the specific answer to this, which is that at 24 bits per pixel, a 32x32 texture consumes 4 kilobytes of memory, while a 16x16 at the same bit depth uses 1/4 of that amount, 1 kilobyte. So you'll save a total of 3 kilobytes by using the smaller size.

I'm not sure why you picked the measurement 16x16, though. Textures in SL can get far smaller than that. They can go all the way down to 8x8. At that size, your 24-bit texture would only use 256 bytes of memory. So you'd save 3.75 kilobytes.

But even that is far bigger than any blank texture really should be. Ideally, if all you need is just a plain solid color, then the texture only needs to be 1x1, which means just 3 bytes worth of memory. But SL doesn't support that size, unfortunately. So for SL purposes, if you're looking for the best possible optimization, go with an 8x8 for anything that needs to be blank.

However, as Kidd said, understand that the savings only occur oncel per texture. You're not saving 3 kilobytes for every instance; you're saving that for the whole thing, which is why I said it's a small benefit. Whether a texture is repeated one time or a hundred times or ten million times, it's still just one texture. Its memory usage stays the same no matter how many times it's repeated.


I'm confused what you mean by this part. Are you stating that you believe uploaded PNG's do not get converted to JPEG2000? If so, I can assure you that that's not the case. All textures, regardless of source file format, are copied to JPEG2000 at the time of upload. The source file never leaves your own hard drive. There's no such thing as a texture in SL that is not a JPEG2000 file. The SL servers don't even know that other image formats exist.




Now that you have your technical answers, let me ask you a question of my own. I'm wondering why you saw fit to mention the name of your island in this post. Clearly it has nothing to do with any of your questions. As a huge sci fi enthusiast myself, I'm of course excited to learn of the presence of this science fiction island of yours. But I'd be less than honest if I did not admit I've got a bit of a sour taste in my mouth over the manner in which you chose to announce it.

I'd really like to take you at your word that your question was legitimate. But there are three things about your post that might cause one to question your intent. First is the fact that you chose not to put it where you'd be most likely to get the best answer, but rather where it would get the most views. Second is the fact that the answer is so readily available, both in the aforementioned sticky, and elsewhere. Third is the fact that you saw fit to mention the name of your soon to be opened island in both the title and the opening paragraph of your post, when it had absolutely nothing to do with the subject at hand.

Taken individually, any one of those three things could easily be taken at face value, and seen as trivial errors. But put them all together, and I can't help feeling like your post is perhaps really a promotional advertisement for your island, thinly guised in the form of a minor technical question.

Maybe that was your intent and maybe it wasn't. I have no way of knowing. All I know is that's how it looks, and in the eyes of many, that kind of thing is not good. If this thread is in fact just an advertisement, that's an abuse of this forum. If that's not what it is, but it just happens to look that way, then I'd advise you to be a little more cautious in the future, so as not to raise suspicion.

Whenever you have a question, great. By all means post it. Just make sure that when you do, you keep your post on topic, and in the right forum, else you risk becoming an annoyance. There's no need to preface a legitimate question by sneaking in a plug for your island or anything else.

And if you do want to advertise your island, that's great too. But please do it through proper channels. Post pictures in the Gallery forum, put something about it in your signature, put an announcement in the Special Attractions forum, purchase an in-world classified ad, etc., etc., etc. In other words, advertise the same way everyone else does. It works. But polluting educational forums with promotional material only angers your readers.

When your island opens, I do hope you'll make some sort of announcement through proper channels. I'd love to come see it.

Minor correction, Peggy. It's actually a 75% decrease, not just 50%. Remember, the size was halved in two dimensions, not just one. A 16x16 is only 1/4 the size of a 32x32.

Great posts everyone

- thank you for all the information. We'll definitely be taking it onboard.

RE: Chosen Few

I truly appreciate your extensively-detailed reply, both on texture usage data and forum posting fronts.

As a mark of respect for yourself and others on the forum, and acting on your inputs, I have edited my original posting slightly based on your comments.

I wish to clarify and assure you that the mentioning of Science Fiction in the title was only to provide a context regarding 'what' we are optimizing for.

Aside from this, no mention of what Science Fiction will offer was ever included in the original post, and therefore, we wish to assure you that the post was never intended to be a running advertisement. Its question and subject matter was/is purely technical. The SF sim has been silent with no formal public announcement to date. When we do announce, we 'will' do this through the proper channels.

We also will do our best to evaluate how we post our forums threads in future, listening to resident comments and respecting the educational nature of this forum.

I hope this reply will ease your concerns somewhat

Once again, thank you all for your inputs; they are highly valued and we will put them to good use.

Sincerely,

DMC Zsigmond

Yeah, stop spamming the forums!


SCiENCE FiCTION
http://www.sciencefiction.info

OR ELSE!!!




SCiENCE FiCTION
http://www.sciencefiction.info

(UPDATE)

We're about to document the data for the initial objects on the entire SIM, so if there's a time to do it, now would be that time

As an experiment, we're going to try 8x8 textures for all opaque and single color prims on the sim, and these will be based on uploaded *.png format files,

yes, it will be marginal, perhaps barely noticed, but at least it will be done.
see how things go

Thanks again,

DMC Zsigmond

I would think, however, that the default texture is a special case which comes installed with the client. At the very least, you can be sure everybody will already have it cached. So replacing it with your own forces people to download a new texture, and if only one single object in your sim uses the default blank, your end result is forcing the use of two textures instead of one. So I'd go against the previous answers here and say no, there is no gain in duplicating existing, well-used and cached assets, but in fact the contrary, by forcing redundant use and cache trashing. (Though the point about the difference being very, very minor is valid here as well).

Yes, I must agree we've observed this upon 1st entry and clear cache logins into the sim.

Prims that are covered with 16x16 textures do appear to take longer to load next to single color prim objects using default colors selected from the SL color palette @ 32x32.

But without specific data to confirm, this has lend to our inquiries.

~~~

The current setup on the sim, is that unless a company logo or image is necessary (256 - 512), all prims are using either default 32x32 Linden textures, or 16x16 single color textures.

As an exercise and for margin performance increase, we are likely to swap out the 16x16s with 8x8s.

Definitive research in this area is our next (i.e. current) task.

Since there will (presumably) be people in this sim, won't using his own blank texture actually result in a net loss, even if it is smaller?

Most everybody will already have the LL version cached (or is it built-in?) and it's not exactly uncommon for content makers to just slap prims with blank/shiny/color.

edit: er.. yeah.. what Tail said above..

All the arguments so far are valid. Here's how it boils down.

If someone already has the Linden blank texture cached, then loading a different one would of course require one extra download. But that only has to happen once. The performance gains from that point on would be permanent and ongoing, assuming that the 8x8 is the only blank texture in the scene.

In other words, however likely it may be that any given person already has the Linden texture cached (and most people probably will at any given time), the fact remains that no texture is in video memory unless it's currently in view. So when you replace the oversized Linden texture with your own smaller version, you're trading a one-time extra download upon arrival in the sim for an ongoing savings in video memory for as long as you're there. I'll take an ongoing benefit over a one-time temporary one any day.

But if it's a mixed bag, with both textures being in use anywhere within view, then that would be a waste all around. Both textures would then need to have been downloaded to cache, and both would also reside in video memory as long as they're on-screen. That's a double handicap. So if you're going to replace the Linden texture (or any texture) you must ensure that your replacement is the only one that every single builder on the island is using. As has been mentioned, if so much as a single prim has either the Linden version or a different user-made version, then all savings are lost, and you're actually worse off than if you hadn't tried to save in the first place.

But either way, the difference is negligible. We're talking about a maximum savings of 3.75 kilobytes, and a maximum overage of 256 bytes (assuming just one Linden texture and one user-made replacement). You'll never notice a difference that small. So it's more a matter of principle than anything else.

When scores of textures can be made smaller, then the difference is noticeable. But when it's just one, it hardly matters in a practical sense.

...and that no visitor carries the default blank texture into view on an attachment.


In particular if you then stack those small textures into one image, and reference the relevant parts by UV coordinates. That way you also minimize the download overhead.

True, but in all fairness, you're no more likely to be able to predict that any attachment will have the Linden texture on it than a custom one. You can only be responsible for the actions of yourself and your builders. It's easy to guess that any given visitor will more likely have the Linden texture on an attachment than some other blank texture, but a guess is all it is. It could so easily go either way, it's not worth investing any concern into it.


Yes. That's always good practice, as long as you're sure all the panels will be in the same scene together.

All Linden assets are built-in and are thus always "cached" (ie, on the users' HD). They never are downloaded.

As another variable of note, yes, all single-color 16x16s on the SF sim are in fact standardized.

And this would logically be carried over to all standardized 8x8s used by all builders the sim.

Absolutely every object on the sim to date is offline data documented, so we're prepared to try a few things, even in principle in the interests of performance and stability,

which must, in principle, include optimizing for or at least analyzing the scripting environment, with some degree of script certification when and where possible. The genre is in the public domain, and we owe it the best possible representation and performance for the community.

DMC

Talarus, that is simply not true. While some of the Linden textures are stored locally, most of them are not.

Want evidence? Here's a simple test. Rez a prim, and apply a Linden texture you've never used before, or that you at least haven't seen in a very long time. The floor tile textures are usually a good example for this, since they're so seldom used. Notice how long you have to wait before the texture appears. If it were "built in" or "always cached" as you had assumed, it would appear instantly. But it doesn't. It downloads, and appears only after a delay, just like every other texture in-world.

The only difference between most of the Linden-made textures and resident-made ones is authorship. Functionally, they're nearly all exactly the same.

There are a just a few permanently local textures, such as bump maps, some tree and plant textures, the "Missing Image" texture, various UI elements, the sun and moon textures, etc., which you'll find in your Second Life/skins/textures folder. Included among these are several blank white images of various sizes. I don't know if one of them is the actual Blank texture or not. But it would be easy enough to find out via the UUID's, if you're so inclined. Notably absent, however, is the Default plywood texture. And if that one's not in there, I'd be really surprised if the Blank one is.

In any case, whether the Blank texture is permanently local or not, the fact remains that it is bigger than in should be. So either way, what we're still talking about is swapping a one-time download for an ongoing savings in video memory.

Chosen, the ones I am talking about are the ones listed here:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=ClientAssetKeys

If you wanna spend the time to prove it to yourself, EVERY SINGLE ONE of those are sitting there on your HD in the C:\Program Files\SecondLife\skins\textures folder. The only exception, as you note, is the default plywood texture. I imagine that it is probably either hardcoded as a resource, or is located elsewhere, but it is still local.

I'm NOT talking about the Linden Library stuff. Of course that isn't already cached; it's a public asset set, nothing more. You still have to download anything in there.

However, you are talking about things like the default texture, the blank texture, and ones like it. Those ARE always cached, because they are always present in the above folder.

Seriously.

Maybe I'm missing something but what's the purpose of being so concerned with optimization to this level? One user with flexi hair or shoes with a couple 512x512 texture in them (sadly common) and many of the little tweaks you've done are going to drop well into the noise.

Just IMO but you'd be better off sticking to standards, especially if you can use assets that you know every user is going to have. If nothing else, it makes it easier on your builders and really doesn't cost you anything...

Sindy, I think the OP's original assumption was that he'd save a bit with every single use of the texture, which could arguably have amounted to something. With that being an incorrect assumption, the talk turned into a more principal discussion about how textures are handled.

But I wholeheartedly agree: The effort the OP seems to be willing to put into optimizing this would almost certainly be put to better use in other areas. There are many things you can work with which would have a much, much larger impact on overall sim and client performance, and unless the OP has already gone through all of those, it is a waste to focus time and attention on such a very minor (and arguably doubtful) optimization, except as a learning experience about the technology.

Ooo.. Right.. Call me Ms Attention Span..

Sorry, Guys, got swamped by RL work piled up for the day... I've mean meaning to reply...

Thanks for your question, Sindy.

Without getting into too much detail, the reason why we are seeking to optimize so much is because there is a RL business behind this, and we believe that over time we will be able to direct enough traffic from off the Internet and within SL that the SIM is likely to be pushed to full capacity. i.e. filled by visitors.

So for that simple reason, we're optimizing everything we can.

DMC Zsigmond

Appreciate your ongoing comments

Basically, yes, your right. It's all been included as part of the sim planning, and while it may seem excessive to look at everything, that's just part of the workflow.

We started integrating offline spreadsheets/ODBC after about 6-months in SL, and this was already effective from the very beginning of the SIM purchase.

Because we try to design with as little prim usage as possible, when we state that we're considering updating all object textures, we don't have anywhere near the 9500+ prim usage of most sims. It's a fair bit less.


DMC

Not to beat a dead horse but if you're expecting tons of traffic, I think that's more of a reason to use standard textures than use smaller, custom ones. Unless I'm totally wrong (which is possible) you'd get wins on users having less to download and having fewer textures on their vid cards. That and your builders will be a little happier.

But, again, I think the blank texture thing is probably well into the noise if you've got any serious traffic going on. One tricked out uberneko (/me pounces!) and a lot of what you're shaving off ends up being like a few pennies saved on a $10k job. Just IMO, though. Good luck with the sim!!