Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Texture optimization

Eggy Lippmann
Wiktator
Join date: 1 May 2003
Posts: 7,939
08-18-2006 06:44
Ok, so asset server issues aside, I am trying to optimize the rezzing time of a build by cutting down on the number, size and complexity of its textures.
The thing is, SL recompresses whatever I upload... and well, I knew it would do that but the outcome is that my highly optimized texture ends up with the same size as the unoptimized one...
(by optimized I mean, cutting down on the amount of colors etc)
I am judging the compressibility by saving them from SL as TGA and converting to PNG, since it is lossless.
I think the JPEG2000 compression thing may be introducing new color values due to compression artifacts. Any thoughts on this, or general advice on optimization?
Cottonteil Muromachi
Abominable
Join date: 2 Mar 2005
Posts: 1,071
08-21-2006 03:43
Visually, JPEG2000 compression produce far less of the colourful dotty artifacts than plain JPG. My question is, what do you mean by having a file the same size.

And where did you get this file size information? None of us actually get to see the file format in JPEG2000 form.

When you save your textures down from SL as a TGA, its a lossless format. So naturally, two files of the same pixel dimensions will be exactly the same size as an 'unoptimized' texture when you do the 'save as'.
Chip Midnight
ate my baby!
Join date: 1 May 2003
Posts: 10,231
08-21-2006 11:46
It would be nice if there was some way for us to see file sizes after the conversion to jpeg2k. I imagine the kind of optimizations you're doing help some, but with the way the asset texture works it's impossible to tell. A minor file size difference probably won't yield much noticeable benefit. The thing that helped my build and boxes rez faster was combining things in to texture sheets, like combining groups of 16 boxes into a single 1024x1024 sheet. Having fewer textures to rez seemed to help a lot more than the texture sizes.
_____________________

My other hobby:
www.live365.com/stations/chip_midnight
Candide LeMay
Registered User
Join date: 30 Dec 2004
Posts: 538
08-21-2006 11:56
You can see the compressed jpeg2000 image - go to 1.12 preview, activate debug menu, go to Client/Compress image... The file will be written in the same directory and name with .j2c appended.

Despite what the file dialog says, it only seems to accept TGAs, not other formats. This is one of the things that migrated to debug from the god mode (i.e. if you use the god mode hack you have Compress image now too)
_____________________
"If Mel Gibson and other cyberspace writers are right, one day the entire internet will be like Second Life." -- geldonyetich
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
08-21-2006 18:56
you could make reduced color images and other tricks, i have messed around with them myself

using reduced pallets do help alittle, sometimes ... back in 1.6.x and before i could show you a noticable diferances between a ...

"rendered in 24 bit", 24 bit image with lets say 12k shades of pink and blue

VS.

a simmilar image that used more of a full spectrum lets say 12 million unique colors... and this is probally still true ... if you can get past the asset load



thats great for things that naturally contain less color, but if you go out of your way to reduce pallet info it can bite you in the rear

ie: Sl will accept 32k color 24 bit images (well most of the time anyway) well jpg2k doesnt really care about the raw pixel data, and when it does its math magic it just makes it a 16 million color image anyways, usually ending up with alot of noise and longer download times (simmilar effect to uploading heavly compressed jpg images)

the best optimization you can do is to keep your images small, but that also doesnt mean upload 1000000000 16x16 textures either, one good way to meet both is using texture maps, basicly cramming all the elements of an object onto 1 texture sheet, then using offsets and whatnot to put the decals in plce

a simple example of this would be a 4 prim 20x20m square floor, you could use 4 unique 256x256 textures or 1 512x512 texture, both take up the same space in video ram and the single 512x512 image means only one (request, find,transfer) asset call vs having to make 4 of them

it helps the asset servers out by putting less crap on them, and as slow as they can run @ times having 1 image load 4x faster (and they all load at the same time) is nice
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
08-21-2006 19:05
ps tga is lossless but i like png also :)
Gearsawe Stonecutter
Over there
Join date: 14 Sep 2005
Posts: 614
08-24-2006 18:38
interesting so with the texture console on. when you select the texture on an object it is highlited in purple in the texture console. An do the little purple squares mean those are the ones you own? Also tells you how much memory it is taking up in your video card.

NOTE: Texture size and info shown is that which is curently loaded into you video card memory. So if the texture is 1024x1024 it might only say 256x256 or whatever till it is fully loaded.