Rez times for big textures if only a prtion of it is visible on a prim

Ok, bear with me here.

I have a number of signs for my store (i.e 'Female T', 'Male T', shop name etc...)

I need to upload these and place them on prims to make the sign.

With about 8 signs, it would be L$80, so my idea was to make one big 1024x1024 texture with all the sign textures on it as 256x256 squares, this would allow me to place them on a 4x4 grid and upload 16 textures at once. (Still with me, hope I explained that correctly).

Now, I rez a prim and apply the texture, then using the repeats per face and offset, I align the big texture so that only one of the 256x256 'signs' appears on the face in question. Then repeat with a different Prim and different 'sign'.


Obvioulsy, this allows me to upload 16 individual sign textures for $10, so is a huge saving, but what are the drawbacks? A single 256x256 would rez much quicker on a prim than a 1024x1024, but what about a 1024x1024 that is 'zoomed-in' to only show a 256x256 section of it, would it still be treated as a full 1024x1024 texture.

Any other drawbacks I've not thought of?

Thanks
PG

OK... Here's the pluses and minuses as I understand them...

It will take 16 times as long to load the HUUUUGE texture as it would to load one of the smaller textures, but I don't know that there would be a difference in how long it took to load 16 small textures or 1 large...
It may also be that larger textures are loaded last. If I were sequencing the image loading, I would take care of the far more numerous small textures first before loading the gargantuan onnes... If this is the case, having the smaller textures would be advantageous because smaller textures would be loaded before the big one.

On the plus side for the big texture, all 16 signs will blip in at the same time, since the texture will be loaded for all of them at once. It's the same for any re-used texture...once it loads, it is painted everywhere it's used.

Personally, I would just pay the L$80. I think that having the textures load faster or at least having some load along the way instead of waiting for all of them to blip in at one time, would be better for consumer retention. Saving L$70 but losing thousands in sales because consumers aren't willing to wait for the yuuge-ass download for your signs is foolish; besides, it's not that expensive if your product is selling well... if it isn't selling well, IM me and we can talk about marketing methods.

Let me elaborate a bit on texture size. On our land we have been doing alot of work cutting down our load times and had great success.

a 256x256 texture takes about 1/4 the time of a 512x512 texture.

The file format of the texture DOES matter. Only use a TGA if you really need some of the special properties of a TGA. USe a JPG if humanly possible. TGA take far longer to load.

Long load times for graphics have many negative impact. Yes its annoying not to be able to see. But, it is also a source of lag for your visitor. Also, textures that take a long time to rez in will likely cost you business. FLipping through the contents of a vendor can be aggravating when textures load. Flipping through when each product picture takes 5-30 minutes to load isn't going to happen. The customer will walk away and you lose a potential sale before they even see your work.

we have been solowly replacing all the textures on our 1/2 sim with 256 jpgs wherever possible. From a cache clearing our load time has gone from over an hour to about 13 seconds (that is what I recorded on my machine and my partner recorded very similar numbers on his)

Hope all this helps and good luck

Let me get this right: You are planning all this hassle to save 30 cents or so (in RL money at current exchange rates)?

IIRC and it's anything like the rest of the net your one big texture should finish loading faster than many smaller ones since only one request is sent and the compression algorythms get to compress them all together instead of separately. We've been doing that on websites for a while.

Unless everyone's been lying to me I don't agree that uploading JPEGs is a good idea though, they all get converted to the same format (JPEG2000) once they're uploaded. I'd guess it may help a tiny amount, but I really doubt it'd noticable.

Wow,

Thanks for the fast replies, I only posted this morning.

I think from what I can glean from the replies is that yes, a bigger texture will take a longer time to rez, regardless of the fact that it's 'zoomed' onto a 256x256 square. BUT, it might still be quicker than rezzing a number of smaller textures. BUT since SL loads smaller textures first, it's still better to go with the individual smaller ones.

These will be on signs, not a vendor, so will only rez once as the person walks up, but I get the point about loosing custom if they don't rez before they leave. On a related note, I loaded 512x512 pictures into my vendor and it does appear to rez the picture after everything else in the store, I'll probably change all these to 256x256.

Pham. LOL. I often get 'swept-up' and forget that it's l$ and not $. I once won $10,000 at a club and had to run and tell my wife. I was a bit deflated when I worked out it was about $30. But, I only selling small atm, $15 T-Shirts in a $50/week store, so every $ (or L$) helps. Plus I'm cheap

For us haveing a Prefab house lot with litterally hundreds of textures in view it did indeed make a huge difference. I have also talked to a couple of lindens and had my discoveries confirmed particularly about size. a 256x256 simply loads faster than a 512x512 or larger. But as I said it is all suggestion take with however many grains of salt desired.

It's entirely possible. We really should bug the Lindens until they make some place where they permanantly keep information about how SL handles things so we know how to optimise stuff properly without running tests every time a release comes out with a vague "improved texture loading" or similar in the features.

According to this page on the wiki, everything uploaded gets converted to JPEG2000, so it shouldn't matter which format you upload in. Is the wiki incorrect?

Let me shed some light on this subject. So far there has been some good factual information and a bit of erroneous speculation. I do "texture sheets" like this all the time, as do most high end texture artists I know, so I've got some experience here. Let me seperate fact from fiction. I'll start with the fiction.

Please note, by the way, that when I call something a fiction, I am in no way calling it a lie, so no one should be offended by these corrections. Hopefully everyone here is mature enough and wise enough not to feel any egotistical attachment to anything they may have said. Facts are facts and non-facts are non-facts, regardless of who said them. My only duty is to the truth. I don't care who said what. If it's wrong, I'll correct it, and if it's right I'll agree with it. Okay, here goes:


Fiction. All images are saved server side as JPEG2000, a format which is neither JPEG nor TGA. Once an image has been uploaded to SL, the source format becomes irrelevant with regard to its new size and resulting transfer speed (rez time). The only factors that affect rez time are the size of the image in pixels and the complexity of its contrast and coloring. In other words, the Mona Lisa will take longer to rez than will a blank canvas. Two different copies of the Mona Lisa, one from a TGA and one from a JPEG will take the exact same amount of time to rez as long as they're both the same size in total pixels.

ALWAYS use TGA. Jpeg is the worst possible choice. JPEG a low quality, very lossy, compressed format, full of artifacts. Every time you open and close a jpeg, it loses quality. When you convert it from from JPEG to JPEG2000, the transition from one compressed format to another causes even further quality loss. It's the whole copy of a copy effect. Jpegs only have one practial purpose, web pages. Other than that, they're totally useless and should be avoided like the plague.

TGA is high quality format, completely lossless, and it's the most commonly used format in 3D. It's pretty much the industry standard format of choice. Like I always say, use TGA, everyday, all the way, TGA!


Fiction. There's a lot more at stake than just the upload fees. Rez time, texture memory consumption, asset server load, network traffic load, etc. are all factors that are directly affected by decisions like this. Partington has asked an important question here, and everyone would do well to learn from the answers and adjust your own activity in SL in accordance with that learning. Poor texture management is the single biggest reason SL is so slow.


Speculation. I've never seen any evidence that textures are delivered in sequence or if they are that that sequence is dictated by size. Experience seems to indicate that they're sent more or less simultaneously since it happens pretty regularly that multiple textures rez at the exact same time, but since that's just speculation of my own, I won't dwell on it.

Whatever the case may be as far as any default order (personally I don't think there is one), what I do know for certain is that the ultimate dictator is the mouse pointer. SL will rez whatever is directly under the pointer first. This is a feature that was added a long time ago so that people could have some modicum of control over what they're looking at. If a texture is taking a while to rez, park your mouse over it, and it will appear within a few seconds.


I don't doubt for a second that the reduction in image canvas size increased your perfomrance considerably. However, I would strongly disagree that using jpeg over TGA prior to upload had anything to do with it. Canvas size and image complexity being equal, a JPEG2000 is a JPEG2000 is a JPEG2000, regardless of from what format it was sourced.

If anyone has any factual information to the contrary, i.e. technical data from LL or from the JPEG committee, by all means please share. Official published information about JPEG2000 can be found at http://www.jpeg.org/jpeg2000/index.html. I haven't read anything stating that final file size or decompression time is affected by source file format in any way, but if you find any hard evidence that it is, please post it. In the mean time, I have to go with what I know.


True. A 1024x1024 contains 16 times the data as a 256x256 so one 1024^2 will take 16 times as long to load as one 256^2. Whether or not the 1024 will load faster or slower than all sixteen 256's together seems to be highly variable. As I said earlier, I've never seen any evidence that there's any rhyme or reason to the sequence in which textures are delivered from server to client. In places with few large textures and many small ones, I've had some of the large ones appear before some of the small ones tons of times.


Correct. This is one of the biggest benefits of texture sheeting. Once the single sheet has rezzed, all objects with any or all of that texture on them appear instantly. So, while a single sign at 256 will rez way quicker than a single sign at 1024, it's entirely possible that the whole fleet of signs using the 1024 would in fact appear well before the last individual 256 would.


Correct. Logically, a single request to the asset server to deliver a single texture is far superior to 16 individual requests and 16 individual deliveries. Texture sheeting is much friendlier to the grid as a whole for this reason than is using lots of small textures.


Correct. As I said earlier, everything server side is JPEG2000. The only possible speed increase resulting from an image that was source jpeg over an identical one that was source TGA would be from the fact that the jpeg would have been lower quality to start with, meaning there'd be slightly less contrast in the image, which would mean uncompressing it for display would take a few less miliseconds to do. If you were viewing 5 or 10 thousand of them in sequence one after the other, you might notice a total accumulated difference a second or two for the entire sequence, but there's no way you'd notice any difference in speed in SL. You will, however, notice a quality difference if you look. Jpeg is ugly, ugly, ugly.


All correct except the last sentence. Again, there's no evidence that smaller textures get delivered before bigger ones. The general consensus among all the top texture artists I know is that sheeting is the way to go.


Vendors are an unusual animal in the texture performance zoo. Every time the image changes, the server has to do work to make the change. Therefore, rez times on vendor screens can be pretty slow. They do seem usually to appear after everything else, even when they're small. It's better to go with 256 than 512 for a multitude of reasons, but be aware that your vendor screens still may end up being some of the last textures to rez.

Thanks CF.

Couple of things I've been wondering (and haven't had time to search through the JPEG200 spec for) are if JPEG200s are stored with the same bit-depth all the time and whether the alpha channel is stored if there isn't one.

...

Hang on, is that the same question?

I'm pretty sure bit depth in the JPEG2000 is the same as the bit depth from the source. If no transparecy channel was present in the source file, none will be present in the JP2. This is fairly easily observable in SL. Save a 32-bit TGA with a totally white alpha. The image won't be visually transparent, but it will contain transparency data because it's 32-bit. Upload it to SL and apply it to a prim. Turn on Highlight Transparent, and you'll see it light up red. Even though there's no visible transparency, the file still contains a transparency channel. Do the same with a 24-bit texture, and it won't highlight.

First let me say there are no hard feelings If I am wrong I am wrong. I am not an expert. I am fuctioning on personal observation in Jouppi and the information given me by 2 Lindens.

As for difference in quality with the Jpgs and the TGAs I honestly can't tell on our textures visually. Thats just how it looks to me with the textures we are working with. I aknowledge it might be very noticible to an expert who looks carefully for such things.



Now this may well be why TGAs load slower for us in Jouppi. Nearly all if not all of them were 32-bit. I can't think of a single 24-bit in the bunch we replaced. Or it might be that it is the level of detail, numbers of colors, what have you in the TGA doing this. I don't know. For us TGA loads much more slowly. That too is fact, if only personally observed by myself and the rest of our family in SL.

Size is the critical issue. As it was explained to me. where it becomes very important is in multiple repeats on a prim. For Example a prim with 3 repeats horizontal and 3 vertical (oe 9 repeats). I have been told SL renders each repeat seperately. Given this 9 repeats of a 256 is much less demanding on the SL systems than 9 repeats of 512.

This is simply what I have been told by persons who should know and personal observation, Not an argument perse. I am not a graphics expert.

Hi Darkness. Thanks for the gracious, thoughtful reply.

I will admit that sometimes I get a bit zealous when discussing image quality. I'll agree that JPEG's that are saved at the highest quality setting, and that haven't been saved more than once can look pretty decent. When a JPEG has been opened and re-saved a few times is when you really start to notice degradation, but first generation copies usually look alright. They won't be quite as sharp as the TGA's would, but I agree it's not something everyone would notice. Assuming you're using max quality (minimal compression) and all JPEG's are first generation (only been saved once), they probably look pretty good. I'd still recommend steering clear of JPEG in the future though.

If as you say, all your textures were previously 32-bit, that would go a long way toward explaining why it's sooo much faster now. 32-bit textures have to make an extra pass through the renderer before they can be displayed, and their file size is 33% larger than that of 24-bit textures. If every texture in the sim was 32-bit, I would imagine things were probably very slow.

As for what you said about repeats, I'm not sure on that one. What I will say is this. A small texture used once will perform better than a large texture used once, so regardless of whether or not that benefit is cumulative with each repeat, it's still a benefit. You can't go wrong with small textures, repeats or no repeats. If the benefit is indeed cumulative, than that's even better, but either way, keep those textures small.

Also, repeating small textures is better than using large ones. For example if you're making a brick wall, with say 40 bricks on it, repeating a small 10-brick texture 4 times will perform better than using one giant texture with all 40 bricks on it.

I betting most of ours are first gen and I know very well they are Max Quality.





I got that information directly from the lindens. Not syaing you are wrong but that is what they told me.



Here we are exactly on the same page

Chosen Few: Thanks so much for your clear concise facts from fiction reply. The only bad thing is, I now have a lot of image resizing and reloading to do

i actually might have to disagree with you here chosen

You simply don't need the maximum image fidelity at all times, so why always save as TGA? If your goal is to minimize lag in your build, then saving a file as a JPG and playing with the compression rate so that it is slightly above the minimum fidelity that you need, would create the smallest file size (thus download time), no? Even when comparing a 256 TGA to a 256 JPG, TGAs seem like overkill in a lot of places.

you're the expert but your insistence on TGA puzzled me

Since all images are converted to JPEG2000 on the server the decrease in filesize by using JPEGs will be absolutely minimal (if any, it's possible it could make the files bigger), yet you're decreasing your image quality. One thing that is worth noting is that you should save a 24bit Targa if there's no transparency.

interesting... this is what comes of not understanding this JPG2000 conversion engine...or perhaps what JPG is really trying to do

If you have a TGA file and you save it at 100% quality JPG, the image size will still be bigger than if you save it at 50% because of the lossy compression.

What i hear you saying is that if you take them both into SL (which then tries to compress them)... the 50% JPG might actually end up a bigger file?

I don't get why the 50% JPG file size (after-load-into-SL) wouldn't still be smaller than the 100% JPG (after-load-into-SL) simply because it had less information in the file.

The thing is, when the server compresses the image it doesn't look at the data in the file as is but the pixels that make up the picture. In order to compress a JPEG it has to uncompress it first.

Any differences in end file size (which will be really tiny unless you've compressed it enough to drasticly affect the image - which looks poo) will be because the uncompressed image is actually a little different.

Easy way to test that theory. Create two identical images and save them in the two different formats, make sure the resulting file sizes are significantly different, upload them into SL, texture them onto a large prim and see which one loads faster. Since both are the same size - 512x512, the only difference between the two texures should be size in bytes. Might test this with 1024x1024 to magnify the difference.

Theory? What theory? Unless I've been told lies and my understanding of image compression is wrong (or JPEG2000 has some wierd 'upgrade' mode that nobody's mentioned) that's just the way things are.

If you do want to test it loading speed isn't a good measure since there's other things involved that affect it. I think there's a panel in debug somewhere that tells you sizes for textures though - you could use that.

As AJ mentioned, when JPEG's are only compressed until they are viewed. When a JPEG file is opened, it gets uncompressed. As long as it's open, it's the same size as any other bitmap. It's only when it's closed that it's small. Think of it kind of like like exploring the contents of a zip file. In order to see what's in it, you have to open it first, which means it has to be unzipped at least temporarily.

For a RL anaology, think of it kind of like mailing a letter. As long as the letter is inside the envelope, it's informationally very small. All you need to know about is that it's got an address and a stamp on the outside, that it weighs a certain amount, and that it's got some folded paper on the inside. Now let's say you want to change the letter's format. Maybe you'd rather have it typed instead of hand written. In order to accomplish this, you must open the envelope, unfold the letter, and read every single word. At this point, the letter becomes informationally huge. It's no longer just a stamped paper package, but a collection of thousands of words, and you need to know all of them or your reformatting effort won't work. After you've finished your typing, you're then free to put the letter back in the envelope and forget all about what it said. It can then remain in that "small" state until it needs to be read again, at which time it will get "big" once more.

How this relates to the JPEG2000 conversion is simple. In order for the conversion to happen, SL first has to open the file so it can "see" all the pixels. Then it takes that raw information, applies JP2 mathmatics to it, and presto, you have a JPEG2000. Since the JPEG while opened is just another bitmap, just like a TGA, the resulting JPEG2000 will be the same size regardless of the format of the source file. Compression is just packaging. Images are images are images.

well thanks for explaining that you two. helpful

I was under the mistaken impression that JPG compression was also shrinking the file itself, not just through compression but through image changes... hence the "lossy" part. To exaggerate an example that was behind my thinking: a 256x256 picture of a black cross on a white background will be tiny, but a 256x256 picture of a forest will be a much bigger file.

learn something new every day

Being an artist in RL and furthering my quest for creativity in VR, I've pretty much learned as I've gained experience which computerized graphic file formats give better resoltion and which save (archive) with the least amount of bytes.

Laughs .. I actually twitch with irritation when people compress .jpg files and render the image to fuzzy hazyness. Quality I say over speed! <grins>

.. and to say the least whilst I do use .jpeg for it's compression abilities, will not readily do so in future .. because I now have a better understanding & insight since learning more about how jpeg files actually function in archive and rezzed mod in a 3D environment (specifically here in SL with it's JP2 engine ) .. an excellent anaology Chosen! Thank you. <smiles>

So in a nutshell if my understanding is correct .. the only benefit in using a jpeg image file in SL would be the fast uploading of the image to the server in it's compressed mode and nothing more.