a case for prim/sim details

In various sims, I've noticed a wide variety of lag, and more crashes in certain sims.

I'm not positive, but I suspect some of this is due to the amount of data being dumped to my client.

I'm thinking it would be really nice if one could tell how many resources are being eaten by the surroundings in any particular spot. For example, stand over here and see that there are 48 prims and 700 meg in textures trying to be displayed to you when you look in that direction, or turn that way and it drops to 26 prims and 150 meg in textures.

Hand in hand with that, it would be good to actually get some idea of how much memory is being used by any particular prim. It doesn't directly affect servers, but it does directly affect clients, and lots of avatars struggling through massive data transfers from a sim might very well affect that server.

It's too easy for users to create a huge 4 color texture, store it as 24 bit, and not have any idea that they could optimize the texture. If users could actually see the details of textures of prims, such as the number of colors and the size of the texture, it would make optimization a bit more likely.

Is there such a way now to do this?

the lowest bitdepth you can use in sl is 24 bit, so apart from size (which everone that knows some science behind textures preaches) what would you add?

That seems strange, since I read that SL converts textures to jpg on uploading. jpg isn't locked into 24 bit as far as I knew.

It also seems strange to me that SL would require a 24 bit texture even if it only has 4 colors.

If SL DOES require 24 bit colors on uploaded textures, I would bloody heck change THAT. Otherwise no matter what kind of compression results you get with jpg, it will be more memory than it has to be.

Sure, once it's fully uploaded it can be stored however they need for fast display, but you'd get far better compression by simplifying it from the start.

But the object information I'm making a case for is still valid, even if nothing could be done about textures themselves, which I highly doubt. Knowing what a sim's texture usage is or an object's texture use is useful info, even if you don't believe it. Getting complete data on the objects you are working with is no less useful than getting information on products you buy at the grocery store.

At the very least, people could use this information in conjuction with problems they encounter to help trace bugs.

But feel free to dismiss my suggeston here as useless and not worthy, but if SL ever actually provides this data, remember to never ever use it.

when you "send" a image to SL it gets compressed to JPG2000, using a propitiatory encoder, and is locked to 24 RGB or 32 bit RGBA

a 512x512 image is squashed to a really small size for internet transfer, a blip, but once it hits your video card it expands back to its raw RGB/RGBA format, so a 512x512 image now sucks down 786k / +1mb of video ram, which is abit piggish for 80% of SL, but since the client is rendering in 32 bit color you would actually loose performance in conversion cycles


its not exactly 4 colors, you can use 4, and the next person use another 4 ect ect ect 72,000 + possible pallet combinations

but again your rendering the client in 32 bit, why make it hard and deal with conversions when your already in 32 bit RGBA

your already rendering a 32 bit scene, long as the textures are decent in size... its been industry standard
i agree


its worthy, id vote for the info tab

but for what its worth you can hit ctrl+alt+shift+T and pull up rez and bitdepth while the edit window is open

opaque = 24 bit, transparent = 32 bit
(((x_pixels * y_pixels) * bitdepth) / = vid ram usage


i propose an offical handbook from the LABS

Hmm. I didn't know of that one. I hope it's better than the shift-control-2 function. I can't make head nor tail of that thing.

I'll try it out. Thanks. Sorry if I came across a bit angry.

Ctrl+Shift+ (3 or 4) brings up some relevant data.. one shows downloading texture sizes and mb's.. the other shows meshes, cached objects and textures etc.. plus any warnings.. these are probably the worst lag offenders as the system tries frantically to find them.

I've seen some pretty bad use of over sized textures used in SL.. a 32bit 1024x1024 texture for a door knob.. in the early days, you paid a tax for each prim you used.. that didn't mean SL was an 'unpleasing to the eye', place to be, it just meant builders were perhaps more creative and less wasteful. It's much the same with bandwidth.. the more we have to make things better, the more we waste and therefore the more we want to compensate.

Each texture costs money (to store/distribute) and bandwidth.. perhaps the answer is, create the ability to use lower forms of textures (size and types), and or apply a scaled 'tax' based on what size is being uploaded. This would perhaps make people more creative and utilise single textures as tiles, and put tiny textures on their knobs.