It is NOT O.K.!

[Drongle McMahon]

"I can't use a 16 x 16 as it is 2 eyes"

But I thought you said you wanted to be able to use separate textures on each eye? If not, just use 16x32 (or 64x128 with my original guesses about size). Another difference is that you woyld be able to use lossless compression at that size (up to 128x128, I think, certainly to 64x64).

PS. If we are taking about 1024x1024 decompressed into gpu memory, that's 3 Megabytes for each eye (without alpha channel). I just read something about compression in gpu memory - up to 4x for the latest version, which would make it 750Kb, but that was all in the context of DirectX and compression is slow, so I would doubt that SL uses it.

[Kwakkelde Kwak]

---

Medhue Simoni wrote:

but just blacking out everything but the eyes on the avatar texture to make each eye color isn't wasting much data.

---

It's wasting huge amounts of data. From another thread I understand this would be a 512x512 texture. I suspect the eyes to be in the 32x32 range, so as Drongle says, for two eyes 32x64. (That is unless you stack the eyes, which would work perfectly fine I guess.)

When someone uses one skin and two different eye colours, they would have to load three 512x512 textures with your setup. That's not a couple of kb on your texture memory, that's 2.25MB. If you had used one 512x512 for the body and two 32x64 textures for the eyes, the memory use would have been 0.75+0.01MB.

I'm having a hard time following your logic and I kind of get the impression that you think a single texture used twice uses twice the amount of memory, OR that you think black canvas space uses less memory than coloury parts.Both aren't the case. It's very simple, if you use a 32x64 pixel area of a 512x512 texture, pretty much the entire texture is wasted.

______

An uncompressed texture uses one byte per pixel per channel. So every pixel is either 3 bytes (3x8=24 bit for RGB) or 4 bytes (4x8=32 bit for RGBA)

So a 512x512, 24 bit texture uses 512x512x3=786432 bytes, which is exactly 0.75 MB.

[Medhue Simoni]

---

Kwakkelde Kwak wrote:

---

Medhue Simoni wrote:

but just blacking out everything but the eyes on the avatar texture to make each eye color isn't wasting much data.

---

It's wasting huge amounts of data. From another thread I understand this would be a 512x512 texture. I suspect the eyes to be in the 32x32 range, so as Drongle says, for two eyes 32x64. (That is unless you stack the eyes, which would work perfectly fine I guess.)

When someone uses one skin and two different eye colours, they would have to load three 512x512 textures with your setup. That's not a couple of kb on your texture memory, that's 2.25MB. If you had used one 512x512 for the body and two 32x64 textures for the eyes, the memory use would have been 0.75+0.01MB.

I'm having a hard time following your logic and I kind of get the impression that you think a single texture used twice uses twice the amount of memory, OR that you think black canvas space uses less memory than coloury parts.Both aren't the case. It's very simple, if you use a 32x64 pixel area of a 512x512 texture, pretty much the entire texture is wasted.

______

An uncompressed texture uses one byte per pixel per channel. So every pixel is either 3 bytes (3x8=24 bit for RGB) or 4 bytes (4x8=32 bit for RGBA)

So a 512x512, 24 bit texture uses 512x512x3=786432 bytes, which is exactly 0.75 MB.

---

 

 

 

Let me tell you the exact numbers and let's see how it works out. The eye texture we are talking about is exported in jpeg at 512 x 512, and is 10kbs. So, you both saying this 10kbs jpeg is actually more data? I guess I understand a little why, but I don't understand exactly why it has to work this way.

What do I know tho, I"m just an animator who dabbles in meshes and avatars cause I need them for my animation projects. That said, animation being directly impacted by fps drops, efficiency is always a concern.

 

[Kwakkelde Kwak]

I'm not quite sure how jpg compression works, but I suspect it kind of works like "this entire area is all black". That's not a lot of data, so the resulting size is small. I don't know the exact technical reasons, but the fact is, SL textures in VRAM are uncompressed. Look at it this way: zip files are smaller than full files and contain all data. You can't use the files when they are compressed though. In order to look at them, you need to uncompress them, that's what happens in the video card before the gpu can understand any of the data. Every single pixel is assigned a (8 bit) value for each channel, so the numbers I posted earlier are the ones you should use.

The size of your jpg on disk before upload is a bogus number for SL, even before it reaches your graphics memory. All textures are stored as jp2 on the SL servers. So bmp images get smaller after upload, jpg images probably a bit larger, depending on the level of compression. Then as they hit your graphics card they are all the same size as a bmp again, or 1/3 higher for the Alpha channel.

[Medhue Simoni]

This is good stuff to know, and I don't think most people would know this before hand. I guess it does make some sense, especially when you are mapping those textures onto surfaces. This also furthers the argument that textures can be a huge issue. I've always known that it is texture data, more than anything else, that is causing a good portion of the lag. It just seems obvious the more time you spend in SL and the more objects you inspect.

Animation, now this, I know, doesn't work anything like textures. Maybe that is why I just assumed textures worked similarly. At the same time tho, I can make basically the same motion capture 300kbs, or 100kbs, with little to no visual difference. Of course, LL has their own compression system, but they can't clean it up too much without changing the animation completely. The interesting part is, the people that get bad results with motion capture are usually trying to use too much fps on an animation that doesn't need it, which makes the movements between frames so small that the uploader ignores the frame.

[Coby Foden]

---

Medhue Simoni wrote:

---

Kwakkelde Kwak wrote:

---

Medhue Simoni wrote:

but just blacking out everything but the eyes on the avatar texture to make each eye color isn't wasting much data.

---

An uncompressed texture uses one byte per pixel per channel. So every pixel is either 3 bytes (3x8=24 bit for RGB) or 4 bytes (4x8=32 bit for RGBA)

So a 512x512, 24 bit texture uses 512x512x3=786432 bytes, which is exactly 0.75 MB.

---

Let me tell you the exact numbers and let's see how it works out. The eye texture we are talking about is exported in jpeg at 512 x 512, and is 10kbs.

---

The file size (in KB, MB, GB..) of an image on disk has nothing to do how much video memory a texture will need.  Blacking out something (like everything else but the eyes) does not help anything. For example completely black 24bit 512x512 texture will use 768 KB of video memory, so does complicated 24bit 512x512 texture - exactly the same 768 KB.

There's an excellent thread about textures and lag, and how the textures actually work in SL.

Textures and Lag - question for Chosen Few

In Chosen's post there is also a chart showing all the texture sizes SL can use, and how much video memory every size consumes.

 

PS.

It's useless to upload textures to SL using lossy JPG format. All textures at upload are converted to JPEG2000 which is also a lossy format. So uploading JPG means double lossyness. Better to use in uploads TGA or PNG files. As said earlier - the file size on disk has nothing to do how much video memory a texture uses. Only things that matter are texture size in pixels and the bit depth (24bit / 32bit).

[Madelaine McMasters]

---

Kwakkelde Kwak wrote:

I'm not quite sure how jpg compression works, but I suspect it kind of works like "this entire area is all black". That's not a lot of data, so the resulting size is small. I don't know the exact technical reasons, but the fact is, SL textures in VRAM are uncompressed. Look at it this way: zip files are smaller than full files and contain all data. You can't use the files when they are compressed though. In order to look at them, you need to uncompress them, that's what happens in the video card before the gpu can understand any of the data. Every single pixel is assigned a (8 bit) value for each channel, so the numbers I posted earlier are the ones you should use.

The size of your jpg on disk before upload is a bogus number for SL, even before it reaches your graphics memory. All textures are stored as jp2 on the SL servers. So bmp images get smaller after upload, jpg images probably a bit larger, depending on the level of compression. Then as they hit your graphics card they are all the same size as a bmp again, or 1/3 higher for the Alpha channel.

---

Kwak, your explanation of SL server texture size vs GPU memory texture size sounds right. The mechanics of JPEG compression are pretty sophisticated and are tuned to our understanding of the way our visual system works. The more detail (high spatial frequency content) in the image, the less JPEG is able to compress it.

But GPU memory usage might be more complicated than just thinking of  uncompressed texture sizes. The viewer loads textures progressively from the servers. You see this when you watch something rez, or when you rebake your avatar. It'll first take on a patchy appearance, then get sharper as the higher resolution data arrives. It's been a long time since I paid attention to such things, but I recall that if I zoomed across my sim, I'd catch far away objects exhibiting that patchy look. They would then sharpen up as I watched. I got the impression that the viewer was not asking for any more resolution than it needed to display a scene. So, an object textured at 1024x1024 that's at the very edge of the draw distance might only load its texture at 64x64 before stopping. The same would hold for a tiny object nearby (like a pearl in a necklace). As you approach an object, the viewer realizes that additional resolution is needed and asks for it, but until you do, I have reason to wonder if the GPU is caching the full resolution texture in RAM.

Once the full resolution textures are loaded into disk cache, they needn't be downloaded again, unless flushed from the cache. But once it's been loaded into GPU memory because you took a close look at the object wearing the texture, it is possible to discard the big texture and keep lower resolution copies as you back away from the object thereby saving RAM. I don't know, I'm theorizing based on knowledge of other rendering systems.

There's a technique called mipmapping that encodes multiple resolutions of a texture in a space that's 4/3 the size of the original texture. Successively less resolute mappings of the original texture are packed alongside the original. This allows the GPU to paint objects that occupy only a few screen pixels with much smaller textures. Rather than trying to mathematically downsample a 1024x1024 texture into a 12x12 pixel space in the scene, the GPU might just downsamples the 16x16 version of the texture from the mipmap. The resulting reduction in pixel manipulations can be tremendous, and sophisticated downsampling algorithms can be used in non-real-time to created the best looking lower resolution textures.

Mipmapping can be done at the server, and maybe that's what we see as our avatars sharpen up after a rebake. The server builds up the entire mipmap starting with some low resolution and ending with the textures uploaded resolution. It would make sense for SL to work this way, distributing only the pixels that will actually be seen.

So, while your comparison of compressed and uncompressed image sizes is valid, and JPEG size means nothing with respect to GPU memory usage, it's probably even more complicated to figure out how texture memory actually gets consumed.

[Medhue Simoni]

---

Kwakkelde Kwak wrote:

---

---

It's wasting huge amounts of data. From another thread I understand this would be a 512x512 texture. I suspect the eyes to be in the 32x32 range, so as Drongle says, for two eyes 32x64. (That is unless you stack the eyes, which would work perfectly fine I guess.)

---

---

Well, you 2 convinced me to redo my eyes. The end result was a 128 x 128 texture for the eyes. I tried to go lower but the resolution just wasn't enough. 128 was as far as I could go without it getting too fuzzy. Now I have to try out my new eyes on the avatar inworld.

[Kwakkelde Kwak]

---

Madelaine McMasters wrote:

So, while your comparison of compressed and uncompressed image sizes is valid, and JPEG size means nothing with respect to GPU memory usage, it's probably even more complicated to figure out how texture memory actually gets consumed.

---

I know I simplified the process. As far as I know you hit it pretty much on the head with how textures are loaded in SL.

Only thing I wonder about is how good SL is at dumping high res textures from memory. I get the impression it doesn't do it at all or if it does, it does it poorly. That would be a reason why lag builds over time, especially when you teleport around a lot. So while it's true for an eye (or anything else small on screen) SL doesn't load the full resolution into the viewer, I'm not 100% sure what happens when you zoom out.

Mipmapping doesn't lower memory use does it? One would think it uses a bit more even since the texture is 4/3 the size. It makes it easier to match pixel and texel, isn't that what it's for?

[Kwakkelde Kwak]

Good for you, good for everyone

[Madelaine McMasters]

---

Kwakkelde Kwak wrote:

---

Madelaine McMasters wrote:

So, while your comparison of compressed and uncompressed image sizes is valid, and JPEG size means nothing with respect to GPU memory usage, it's probably even more complicated to figure out how texture memory actually gets consumed.

---

I know I simplified the process. As far as I know you hit it pretty much on the head with how textures are loaded in SL.

Only thing I wonder about is how good SL is at dumping high res textures from memory. I get the impression it doesn't do it at all or if it does, it does it poorly. That would be a reason why lag builds over time, especially when you teleport around a lot. So while it's true for an eye (or anything else small on screen) SL doesn't load the full resolution into the viewer, I'm not 100% sure what happens when you zoom out.

Mipmapping doesn't lower memory use does it? One would think it uses a bit more even since the texture is 4/3 the size. It makes it easier to match pixel and texel, isn't that what it's for?

---

Yeah, I've no idea how SL manages GPU memory either. If it doesn't dump high resolution textures for objects no longer needing them (because they occupy only a small number of pixels in the scene) then the system will start choking quickly. It's not only a matter of memory usage, but as you move away from a high resolution object, the renderer must scale down the texture. If it wants to do that well, it'll have to examine every pixel in the original texture to compute the scaled texture. That would quickly bring the system to its knees, as even a one pixel thing off in the distance could require the squishing of four megabytes of texture data (1024x1024xRGBA). I'm pretty sure the viewers don't scale that way, because people have been taking advantage of high resolution pattern textures to create "shimmer". A great scaling algorithm would not create shimmer, so we can presume that SL's texture scaling isn't great.

Mipmapping can actually lower memory usage if it's done correctly. It's true that a full mipmap takes 4/3 the space of the base texture, but you needn't load the entire map if the object occupies only a small portion of the scene. You'd only load that portion of the map that corresponds to the apparent resolution of the texture. The beauty of mipmapping is that it allows you to use that great scaling algorithm to create a cascade of scaled textures in the map. This can be a computationally intensive thing, so doing it offline saves the GPU from doing it during scene rendering. You get the benefit of visually accurate texture scaling without having to do it in real time. You still have to scale a bit, as the mipmap only provides textures in 2x resolution steps, but it's a lot easier/faster to scale something by less than 2x than by as much as 512x.

If SL viewers were using mipmapping, I don't think I'd have seen that beautiful shimmering evening gown worn by an avi at Frank's the other evening.

Sometimes doing it wrong is oh so right.

[Kwakkelde Kwak]

---

Madelaine McMasters wrote:

If it doesn't dump high resolution textures for objects no longer needing them (because they occupy only a small number of pixels in the scene) then the system will start choking quickly. It's not only a matter of memory usage, but as you move away from a high resolution object, the renderer must scale down the texture. If it wants to do that well, it'll have to examine every pixel in the original texture to compute the scaled texture. That would quickly bring the system to its knees, as even a one pixel thing off in the distance could require the squishing of four megabytes of texture data (1024x1024xRGBA).

---

Dumping the texture from memory and not using the texture are two different things of course. One would have to zoom out then in and see what happens. I'm a fraid my computer is a bit to fast to notice the difference between loading from cache, loading from RAM or loading from VRAM. Might be worth having a go at it though.

---

Mipmapping can actually lower memory usage if it's done correctly. It's true that a full mipmap takes 4/3 the space of the base texture, but you needn't load the entire map if the object occupies only a small portion of the scene. You'd only load that portion of the map that corresponds to the apparent resolution of the texture

---

So if I understand it correctly, the entire mipmap is stored in RAM (taking up more space there) and only the part needed to draw the screen is loaded into VRAM (taking up less space there)? That makes sense. I always thought the entire map was stored in VRAM.

---

You get the benefit of visually accurate texture scaling without having to do it in real time. You still have to scale a bit, as the mipmap only provides textures in 2x resolution steps, but it's a lot easier/faster to scale something by less than 2x than by as much as 512x.

---

That's what I meant with the matching of pixel and texel.

 

 

[Madelaine McMasters]

---

Kwakkelde Kwak wrote:

---

Madelaine McMasters wrote:

If it doesn't dump high resolution textures for objects no longer needing them (because they occupy only a small number of pixels in the scene) then the system will start choking quickly. It's not only a matter of memory usage, but as you move away from a high resolution object, the renderer must scale down the texture. If it wants to do that well, it'll have to examine every pixel in the original texture to compute the scaled texture. That would quickly bring the system to its knees, as even a one pixel thing off in the distance could require the squishing of four megabytes of texture data (1024x1024xRGBA).

---

Dumping the texture from memory and not using the texture are two different things of course. One would have to zoom out then in and see what happens. I'm a fraid my computer is a bit to fast to notice the difference between loading from cache, loading from RAM or loading from VRAM. Might be worth having a go at it though.

My recollection is that once I've cammed into something small/far away, I can watch the higher resolution textures load from the servers (and I can see the bandwidth spike in the statistics bar). If I then leave and and return, I don't see that. But as you say, by that time the textures have been loaded from the servers to disk cache. You and I can probably not tell whether the a texture had been flushed from VRAM or main RAM. It would be reloaded from disk very quickly. We only detect the progressive download of the textures from the SL servers.

---

Mipmapping can actually lower memory usage if it's done correctly. It's true that a full mipmap takes 4/3 the space of the base texture, but you needn't load the entire map if the object occupies only a small portion of the scene. You'd only load that portion of the map that corresponds to the apparent resolution of the texture

---

So if I understand it correctly, the entire mipmap is stored in RAM (taking up more space there) and only the part needed to draw the screen is loaded into VRAM (taking up less space there)? That makes sense. I always thought the entire map was stored in VRAM.

If it were done well from stem to stern, the viewer would only load the levels of the mipmap it needed from the servers at the time. I think this may be how SL does it because I recall camming across sims to see things of interest, long after arriving on the sim (so you'd think all textures would have loaded) and still seeing fuzzy textures become crisp. If I'm remembering that correctly this would suggest that the viewer asked for only those levels of the detail it needed when I arrived, then asked for higher levels as I cammed closer to distant objects. Whether the lower resolution textures were stored in the server as part of a mipmap, or whether the SL servers computed the lower resolution textures as needed from the original full-rez texture I can't say.

I don't think the SL viewer actually does mipmapping on its own, as that would be inconsistent with the presence of shimmering texture. Shimmer is really "subsample aliasing" in disguise. To produce a visually accurate reduction of a texture, you'd have to include every texel of the original texture in the reduction, using averaging or some similar operation to make each reduced pixel accurately represent all the texels it replaces. That's a lot of work for a large texture!

But, if you do something simple, like reduce 16:1 by looking at every 16th texel of every 16th row of the texture, you dramatically reduce the computational load, and produce potentially bizarre output. It is exactly that method that produces the truly pretty shimmering I saw on that gown at Frank's the other evening. In fact, you can get colored sparkles from a B&W texture, entirely due to math errors in the texture reduction. I cammed into the gown in question the other night and saw that the pretty multicolored sparklies were coming from a B&W texture.

So, the viewer may load textures progressively from the servers, but it's possible that the end result on the viewer side is not a mipmap, but just the highest resolution version of the texture loaded to date. The viewer then uses that large texture to render even the smallest areas of a scene, using a crummy reduction algorithm. Whether that large texture is stored in VRAM or elsewhere, I don't know. If it's stored in VRAM, then ouch!

---

You get the benefit of visually accurate texture scaling without having to do it in real time. You still have to scale a bit, as the mipmap only provides textures in 2x resolution steps, but it's a lot easier/faster to scale something by less than 2x than by as much as 512x.

---

That's what I meant with the matching of pixel and texel.

---

 

[Kwakkelde Kwak]

SL is progressively loading levels of detail, not exactly the same as a mipmap or parts of it. This is to prevent overload of the network, not so much your computer. I'm pretty sure you remember that correctly.

We can see a bit more clearly what happens by looking at sculptmaps. As far as I know, sculptmaps are treated the very same way as textures (the variable for on screen pixel replaced with on screen size?), I might be mistaken though. Anyway, if this is the case, it's clear that the server sends a reduced resolution texture by sampling every other pixel, not an average which is done with mipmapping. The position of sculptmap vertices on lower LoDs is exactly the same as those same vertices on a higher LoD, which, like your shimmering effect, indicates that this is how the texture size is reduced.

Again looking at sculptmaps, still assuming textures are handled the same, the viewer will use a lower LoD texture when you zoom out, not a part of a mipmap. If this was the case, sculpties would get scrambled or rounded if you zoom out of a fully loaded shape. Also, the shimmering effect would be gone. In other words, the lower LoD textures have to be stored somewhere, not replaced with a high resolution one. Another way could be the viewer downsampling the texture on zooming out, that doesn't sound as efficient as storing all sizes in cache or RAM or VRAM though. Both ways mean high resolution LoDs can be dumped from VRAM or even RAM, which is good news. (Whether that's done very efficiently is a whole other matter.) The viewer shouldn't dump everything not needed right away I'd think. When camming around, that would mean loading, dumping, loading, dumping of huge amounts of data. Maybe there's a delay, maybe there's some code predicting whether the texture will be shown at a higher LoD again anytime soon. I just don't know.

I don't have time, nor the will to go through all of this, at least not now. I think most if not all answers can be found on the page.