[sldev] RE: Reformatting Textures for the cache

[Judith Combs]

Thank you John and Dzonatas, I'm thrilled that you guys are thinking about this.  What you (Dzonatas) are saying about not needing to rez so much from a distance makes sense.  I'm not sure what you mean by "old images"?  Are those textures that are in inventory but not on a prim somewhere and haven't been used in a while?

I'm concerned about close-up views of unique textures, used once in an artwork, that are useless unless they rez with high detail.  Examples:  Photographs in my gallery by another artist ( TGA, 1024x1024, 2305KB).  Reproductions of 18th botanical prints that I'm using for customizing sailboats and jetskis, with matching tattoos and clothing (TGA, some alpha, 1025-4097KB).  BMP snapshots that load to Photo Album as I take them - file size isn't noted in-world, but I think they're about 5MB.  I'm using the snapshots, along with reproductions of 19th century paintings, uploaded sounds and stock animations, in a collaboration with a machinima artist.  None of these textures need to flow with the textures in their proximity, they're either all there, or they're no good at all.  Avatars who come to the gallery don't seem to mind waiting a few seconds for the pictures to rez, they sit in the nice sofa - I sell a lot of copies of that sofa, go figure.

When I'm making structures like buildings and landscape, I use the Linden library textures wherever possible; they do rez the fastest.  And as John correctly points out, the fewer and smaller textures the better (information I wish I had been able to find when I first started building, instead of only a month ago!).  When I'm working on something like a vehicle, that's exactly how I handle it now, not difficult at all to do in PhotoShop.  And thank you!  I didn't know about Compress Texture in Client menu.

But it's also not uncommon for me to want to "try out" dozens of textures on a sculpture before figuring out what works on which surfaces, which leads to the other lag issue:  the way textures are handled in Inventory.  Sounds and Animations can be stashed in boxes and tried out one at a time before plucking them out of the box and into a build.  I can't do that from a box of textures, nor with any of the other scripted texture systems I've tried, so thousands of textures in my Inventory must load before I can see how one might work.  I keep my total Inventory below 5000 items, total, but 4000 of those are textures, and only down to that low number because of boxing most of them.  It's awkward, and stalls the creative process.

Again, thank you (a lot) for working on this.

Date: Thu, 22 Mar 2007 09:42:47 -0700
From: Dzonatas <dzonatas at dzonux.net>
Subject: Re: [sldev] Reformatting Textures for the cache
To: sldev at lists.secondlife.com
Judith Combs wrote:
> So are you saying that unique new textures wouldn't rez well?  That 
> sounds like hell for artists (content creators) like me.  I'm reading 
> this thread with fascination, and it's already changed the way I 
> handle textures now, for the better.  (And I think that more education 
> that's easier to find, for the non-programmer-content-creators would 
> be a good idea, so we don't do so many dumb things.)  But I think this 
> idea would drive content creation to a more mediocre level, instead of 
> encouraging new and original visual ideas. 
We want to encourage a more colorful experience over gray. You would not 
get any less hi-res images as you do now.

An uncompressed image takes about 1 to 3 megabytes.  These images are 
stored in memory.

A compressed image takes about 70-300 Kb. That would be about a10x file 
size reduction. These compressed images are stored on disk or sent over 
the network.

Normally, images are either compressed or uncompressed. To make room for 
more images, old images are just deleted.

We offer a way to keep old images by the use of further compression.  A 
3 megabyte file compressed down to 5kb would be just a blur, yes. 
However, it will give you the right overall shade, tint, contrast, hue, 
and maybe some detail to flow with the textures in its proximity instead 
of gray.

We could store up to 600 squished images in the space of one 3 megabyte 
image, or that's about 10-40 squished images instead of one normally 
compressed image.

If you even dedicated 1GB to these little 5kb squished images, you could 
store 200,000 of them.  That is a much more colorful and greater 
impression than over plain gray.

If you never go near a image in the far distance, you really don't need 
to download the entire image, also. The squished 5kb image will work 
especially well for that.

From: John Hurliman <jhurliman at wsu.edu>

Judith Combs wrote:
> So are you saying that unique new textures wouldn't rez well?  That 
> sounds like hell for artists (content creators) like me.  I'm reading 
> this thread with fascination, and it's already changed the way I 
> handle textures now, for the better.  (And I think that more education 
> that's easier to find, for the non-programmer-content-creators would 
> be a good idea, so we don't do so many dumb things.)  But I think this 
> idea would drive content creation to a more mediocre level, instead of 
> encouraging new and original visual ideas. 

The best thing you can do as a texture artist to optimize your work for 
SL is reusing textures. Lets say you are making a car; instead of 
uploading a separate texture for each piece of the interior, the grill, 
the windshield, the mirrors, license plate, etc., make a single 512x512 
image and put each texture in a different part of the 512x512 image. Use 
the Compress Texture menu item under the Client menu in Second Life to 
test out the JPEG2000 compression locally without having to spend L$10 
uploading and realize the text on your license plate was destroyed.

John Hurliman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070322/907d854a/attachment.htm