Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Texture Size, Pixel Counts, Video Memory, and File Formats

Chosen Few
Alpha Channel Slave
Join date: 16 Jan 2004
Posts: 7,496
11-21-2006 19:56
There have been several questions lately on the subject of texture size, so I figured it might be helpful to have an informational thread on the topic. Hopefully this will answer many of people's questions before they come up.

IMAGE FILE FORMATS (SOURCE)

SL allows you to use any of four different image formats as your source files for uploading, TGA, BMP, JPEG, and PNG. Here's a bit of brief info on all three:

TGA - TARGA File Format

Advantages:

* High quality
* Entirely lossless
* Supports transparency
* Entirely predictable file size
* Simple bitmap formatting is easy for all computers to read
* Industry standard format for textures, also used extensively in video applications

Disadvantages:

* Large file size
* Not readable by low-end graphics programs or by programs not intended for serious graphics work (you can't view a TGA in Windows Picture Viewer, for example)
* Not well suited for printing

History:

* Invented in 1984 by Truevision for TARGA graphics cards
* Upgraded to its current version in 1989
* Stand for Truevision Advanced Raster Graphics Adapter
* Was the first file format to support truecolor on IBM compatible PC's


BMP - Windows Bitmap Format

Advantages:

* High quality
* Entirely lossless
* Entirely predictable file size
* Simple bitmap formatting is easy for all computers to read

Disadvantages:

* Large file size
* Does not support transparency
* Not well suited for printing
* Not a common format of choice in the graphics industry

History:

* Developed in the 1980's by Microsoft as an image standard for the Windows operating system
* Today, it's used for simple things like desktop wallpaper images, not much else


JPEG - Joint Photographic Expert Group Format

Advantages:

* Small file size
* Viewable in almost all programs

Disadvantages:

* Lossy compression
* Image quality degrades every time it's saved
* Does not support transparency
* Not well suited for printing

History:

* Invented by the Joint Photographic Experts Group in 1986
* Today, it's the most commonly used image format on the web, the last place where file size is still more important than image quality.
* It's also commonly used in digital cameras, but that's changing fast.


PNG - Portable Network Graphics Format

Advantages:

* Lossless compression
* Fairly small file size
* Supports both alpha transparency and simple transparency
* Supports a wide range of color depths

Disadvantages:

* Not readable by all programs
* Not well suited for printing
* While PNG file size is small, it's not as small that of a JPEG
* Greater margin for error in bit depth conversion upon upload to SL than with the other three formats

History:

* Originally conceived in 1995 as a potential superior replacement for the GIF format
* Unlike GIF, PNG has never been patented
* First released in 1996
* Became an international standard in 2003
* Popularity is steadily growing, but it's still not all that commonly used, relatively speaking



When you upload an image to SL, it gets stored on the server in JPEG2000 format, an optionally lossless type of compressed file. I won't bother posting much information about it since SL's implimentation of it is outside our control as users. If you're curious, you can read all about it at http://www.jpeg.org/jpeg2000/index.html .

For best results in SL, I recommend always using TGA as your source file format. TGA has been an industry standard format of choice for texturing for many years. PNG is another good option, but I don't recommend it as strongly. Since PNG supports multiple types of transparency, SL sometimes has trouble determining proper bit depth when converting it to JPEG2000. It's not uncommon with PNG to end up accidentally with a 32-bit texture where a 24-bit one was the intent. But with TGA, you can't go wrong. The alpha channel is either there (because you put it there on purpose) or it isn't. There's no possibility of error in that regard.

I recommend not using JPEG ever for texturing. It's great for web pages, but it's not well suited for 3D work. Since the SL servers will store your images as JPEG2000 anyway, there's no need to be concerned about file size, which nullifies JPEG's one and only real advantage, leaving you with nothing but all the disadvantages. It's a lossy, low quality format.

Also, since SL's implimentation of JPEG2000 is a bit lossy, using a JPEG as your source image just compounds the problem. When you source your upload from a losslesss TGA, you only compress once, and only lose quality once. When you source from a lossy JPEG, you compress twice, and lose quality twice. It's akin to the "copy of a copy" effect.

If you're a web designer, use JPEG all day long, by all means, but if you're a 3D texture artist, steer clear of it. For texturing work, like I always say, use TGA, every day, TGA all the way.



FILE SIZE VS. TEXTURE MEMORY

It's not uncommon for those new to texturing to assume they should use highly compressed formats like JPEG out of the mistaken belief that keeping file sizes small will increase performance. People usually come by this presumption as a result of every day experiences using the internet, where it's easy to see that web pages load faster with smaller image files than with larger ones. For the novice, the expectation that this same behavior would apply equally to graphics applications is logical, but it's incorrect.

The perceived correlation between file size and speed on the web actually is an illusion which has nothing to do with graphics processing. Where the internet is concerned, speed is primarily determined by the rate at which files can be sent from computer to computer. Since smaller files have less information to deliver, of course they get delivered faster.

The rate at which graphical images are processed on screen though actually has nothing whatsoever to do with file size. Graphics processing is all about texture memory, not about storage space.

Texture memory is always determined by the amount and depth of the actual pixels in the image, not the bits and bytes in which the file is stored. The amount of pixels in an image times the number of bits in each pixel will always equal the amount of texture memory the image uses, no matter what. Its file size can vary depending on in what format it is saved, but its actual texture memory consumption when the image is in view will always be the same.

Why that's important to the SL texture artist is pretty simple. Knowing the rudimentary mathematical principles of how images affect performance enables you to optimize your textures so you can ensure your creations are as lag free as possible while also being as high in quality as they can be. The key to success in any real time graphics application is always finding the right balance between detail and speed. Make your textures too big, and you use too much memory, slowing down your frame rate (and everyone else's). Make them too small, and while your system performance will be relatively good, your imagery might look terrible.

File size is not part of the equation when thinking in this context. What's relevant to performance and visual quality are the actual images, not the files that store them on hard drives. Graphics performance is affected not at all by file size, but by texture memory consumption. Texture memory is determined by the amount of pixels that make up each image, and the amount of memory bits in each pixel. That's it.

(For more on bits per pixel, by the way, see the Transparency Guide, stickied at the top of this forum.)



HOW TO CALCULATE TEXTURE MEMORY

Determining how much texture memory an image will consume is fairly straight forward. It's basically a count of the total amount of pixels in the image, multiplied by the number of bits in each pixel.

RGB color images without transparency have 24 bits per pixel, and those with transparency have 32 bits per pixel (see the Transparency Guide for more on this). So, for example, if you've got a non-transparent color image that is 1024x1024 pixels, here's how the math would break down:

1024x1024 = 1,048,576 total pixels
1,048,576 x 24 bits in each pixel = 25,165,824 total bits in the image
25,165,824 bits / 8 bits in every byte = 3,125,728 bytes, or precisely 3 megabytes

Pretty simple math. A 1024x1024 image (sans transparency) will always use exactly 3 megabytes of texture memory. That's regardless of whether or not the file is compressed for storage. As far as the graphics card is concerned, an image is just a collection of pixels to be drawn, not a file to be saved.



ALLOWABLE TEXTURE SIZES & RESPECTIVE MEMORY USAGES

OpenGL, the graphics language in which SL is written, requires the heights and widths of textures to be measurable in powers of two. SL has further restrictions of its own in order to keep texture sizes reasonable, and to ensure compatibility with as many video card makes and models as possible. The allowable dimensions are all powers of two from 8 to 1024. (That means 8, 16, 32, 64, 128, 256, 512, and 1024, nothing else.)

Should you attempt to upload an image that is not correctly sized, SL will resize it for you to make it work. Anything smaller than 8 will get upsized to 8, and anything larger than 1024 will get downsized to 1024. Numbers that fall in between will usually end up rounded down to the next lowest power of two (300 will get downsized to 256, for example). In some cases, if a number is very close to the next power of two up, SL will upsize the image instead of downsizing it (511 will upsize to 512).

Even though SL does possess this ability to resize images at the time of upload to make them compatible, for aesthetic reasons it is not recommended to upload incorrectly sized images. SL can't and won't do as good of a job visually of the resizing as a dedicated 2D image editor like Photoshop would. So while an SL-resized image will be technically usable, it won't look as good as it could have had it been sized correctly from the start. For best results, always presize your images to powers of two in a good raster editor like Photoshop, Paintshop Pro, or GIMP before you upload them.

For informational purposes, here's a quick breakdown of all the texture sizes SL allows, and their corresponding texture memory requirements (please let me know if anyone spots any typos in this):



Notice how much memory the larger textures demand. It doesn't take all that many to overwhelm a 256MB or 128MB video card. The biggest reason SL operates as slowly as it does is because of poor texture management on the part of resident content creators. Many people use textures that are simply way too big, and as a result, video cards choke.

The average video card can only process a few hundred megabytes worth of textures at a time. Professional game artists are well aware of this, and so they make sure to optimize all their textures to keep them as small as possible. SL, as a mostly amateur-created environment does not tend to benefit from the same professional wisdom, and as a result, an average busy scene in SL can have literally gigabytes worth of textures on display. Obviously, that's not a formula for effective real time performance.

For everyone's sake, always keep all textures as small as they can be. I usually suggest as a rule of thumb that about 80% of textures should be 256x256 or smaller, about 15% should be 512x512, and about 5% should be 1024x1024. SL is extremely good at displaying small textures on objects at full screen size, better than just about any other program I've ever seen, in fact. It's quite rare that there's a legitimate reason to go much larger than 256x256.



CHOOSING THE BEST TEXTURE SIZE FOR THE JOB

The two most important factors in determining what size to make a texture is to think about how much screen real estate that texture is likely to occupy, and how much fine detail does it really need relative to its size.

For example, if you're doing a life size replica of the Sistine Chapel, with giant ceiling murals that are likely to fill the entire screen, and with lots of fine details that people are likely to zoom in on and study, go with 1024's by all means. However, for the parts that aren't likely to fill much of the screen, like your little donation box next to the front door that no one's gonna look at, use something MUCH smaller.

Of course, just because something will fill the screen doesn't automatically mean it demands a large texture. A brick wall, for example, is just a repeating pattern. The pattern itself doesn't need to be very big to be effective. You could paint just a few bricks in exquisite detail at maybe 128x128, and then repeat the texture across the wall surface many times via the repeat and offset settings inside SL.

If the wall needs other details embedded into it like windows, doorways, creeping vines, etc, then it's no longer just a repeating pattern; it's a whole painting. In that case, you'll need to go larger with the texture to fit all those things in.

What you want to avoid is doing things like slapping a 1024x1024 on a little 2-word sign that no one's ever gonna zoom in on. For that, something as small as a 64x64 would probably be plenty. Always make every texture only as large as it needs to be, not one pixel more.

Again, it's all about finding the optimum balance between texture memory and texture detail. That means using good, sound judgment. Choose your texture sizes carefully. Make appropriate decisions.


I hope this information has been helpful. I'm sure other knowledgeable folks will have more to add.
_____________________
.

Land now available for rent in Indigo. Low rates. Quiet, low-lag mainland sim with good neighbors. IM me in-world if you're interested.
Cal Prefect
Dark Avenger
Join date: 5 Jan 2005
Posts: 160
11-22-2006 04:32
Chosen, this is awesome! As always :)

Thank you, this will be a great help to the designig community :)

Someone Sticky This Please
_____________________
Ceera Murakami
Texture Artist / Builder
Join date: 9 Sep 2005
Posts: 7,750
11-22-2006 07:03
Fantastic article Chosen! You rock!

Discussions like this one are one of the reasons I've reduced the size on many of my building textures that I sell to 256 x 256 or 256 x 128. For most situations, that is sufficent for a door, a window, a shutter... For whole wall textures, I'm moving to 512 x 512 or 512 x 256.

However... I'm still not sure for things like a whole wall with an alpha-mapped window or multiple alpha mapped windows, where it is to be displayed on something like a 10M wide x 5M high wall. When I try doing those at 512 x 256, they don't look anywhere near as good as the same wall at 1024 x 512.
_____________________
Sorry, LL won't let me tell you where I sell my textures and where I offer my services as a sim builder. Ask me in-world.
Chosen Few
Alpha Channel Slave
Join date: 16 Jan 2004
Posts: 7,496
11-22-2006 07:56
Thanks for the compliments, guys. Ceera, thanks for the addition. You reminded me of something I had forgotten to put in (I was interrupted at least a hundred times while writing the OP), which was a section on choosing appropriate texture sizes for each job.

I just added a little blurb on the subject, which I might amend further later to be a little more complete. For now, I think it gets the point across, even if only generally. If anyone has any more to add, fire away. This is an important topic.

Thanks again.
_____________________
.

Land now available for rent in Indigo. Low rates. Quiet, low-lag mainland sim with good neighbors. IM me in-world if you're interested.
Eloise Pasteur
Curious Individual
Join date: 14 Jul 2004
Posts: 1,952
11-22-2006 08:15
I'll repeat the call to sticky this.

I'd add that man-made things almost always repeat. Wallpaper, carpet patterns, brick walls, wooden walls etc. so try to go small.

I'm sure the contributers here so far know, but for the sake of the curious:

Although not strictly about textures, remember there can be building solutions to smaller textures too. A window in a wall can be a prim in a hollowed prim. You may well find the window texture can then be small, and the wall material texture too. This is an extra balancing act, absolutely: extra prims and loading an extra small texture or two against fewer prims and a larger texture.

There isn't a right answer to this. Welcome to the wonderful world of being an adult and having to make such tricky choices.
_____________________
Eloise's MiniMall
Visit Eloise's Minimall
New, smaller footprint, same great materials.

Check out the new blog
Lee Ponzu
What Would Steve Do?
Join date: 28 Jun 2006
Posts: 1,770
big non-tiled objects
11-22-2006 08:36
From: Ceera Murakami


However... I'm still not sure for things like a whole wall with an alpha-mapped window or multiple alpha mapped windows, where it is to be displayed on something like a 10M wide x 5M high wall. When I try doing those at 512 x 256, they don't look anywhere near as good as the same wall at 1024 x 512.


he covered that when he said to think about how much *screen* the image would occupy. If a wall or some such will occupy a large part of the screen, then a low resolution image will not look as good as a higher one.

Artistically, it seems to me that the next questions is whether you *want* the wall to look so good that it distracts from something else. In photography, you often blur the background...same thing applies here. A boring wall should probably not be brilliantly attractive. Of course, in some cases, it should. Maybe it is the Grand Ballroom of the Sun King, or something.

Maybe it would be a good client-side option to set a max res for textures.
Johan Durant
Registered User
Join date: 7 Aug 2006
Posts: 1,657
11-22-2006 08:39
From: Eloise Pasteur
Welcome to the wonderful world of being a digital artist and having to make such tricky choices.

Sounds a little less grandiose and thus palatable.
_____________________
(Aelin 184,194,22)

The Motion Merchant - an animation store specializing in two-person interactions
FD Spark
Prim & Texture Doodler
Join date: 30 Oct 2006
Posts: 4,697
11-22-2006 10:21
thanks for reposting this chosen few. I had friend in game who suggested I look for your post on textures but I was so tired I couldn't seem to find it within all the pages of post.
Cocoanut Koala
Coco's Cottages
Join date: 7 Feb 2005
Posts: 7,903
11-22-2006 10:49
I never did understand this. Thanks for the breakdown!

coco
_____________________
VALENTINE BOUTIQUE
at Coco's Cottages

http://slurl.com/secondlife/Rosieri/85/166/87
Torley Linden
Enlightenment!
Join date: 15 Sep 2004
Posts: 16,530
11-22-2006 12:30
I've stickied this thread so it's easier to find -- I've asked some of those questions myself, and've heard them a lot over time. Another great article, thanx so much Chosen. Nice formatting too. :)
_____________________
Blaze Columbia
on Fire!
Join date: 21 Oct 2005
Posts: 280
11-22-2006 12:59
Very well done Chosen. This thread is too good for a stickie, it should be added to SL's manuals. However, I did add a link to this thread in the 'Great Links' thread.


Btw, you wrote above that a JPG loses quality every time it is viewed, but it's really every time it's saved.

And, one thing that I might point out: we all make choices in how we do things and everyone does what works best for them. Whereas Targa's are the obvious choice for any clothing articles and building textures, I disagree with your suggestion to NEVER use jpegs. One factor you didn't consider was workflow.

All the vendor posters in my store are from jpeg images for the reason of streamlining my workflow and minimizing my file management needs. As you admit, most image hosting sites on the web do not support targa. Some do, but sites like slboutique, imageshack, blogging sites and even the SL forums will not allow you to upload a targa file for viewing. Instead of making a targa file for Second Life AND a jpeg version of my vendor posters for online display, I simply make one jpg file. I concede that there may be a miniscule hit on image quality since i used jpg format on my vendor posters in Second Life. But on the other hand, as many of you know, I am picky about quality, and if my vendor posters didn't look good or represent my product well, I would not use jpgs. But that is not the case, so I save time and file management issues by simply using a jpg version of my vendor posters for all my needs.

Of course, jpg's advantage in this case would disappear if I were not displaying my product on websites. So until I either drop all website based advertising or targa is accepted by all the hosting sites (and uploads near as quick as a jpeg), I will continue using jpgs for vendor posters.


But all in all, Chosen, very well, done :) thnx!!!
Chosen Few
Alpha Channel Slave
Join date: 16 Jan 2004
Posts: 7,496
11-22-2006 17:22
Thanks everyone for the numerous compliments on the OP, and Torley, thanks much for the sticky.

Blaze, you've raised some great points. I love how many talented, knowledgeable people frequent this forum, and can add to these kinds of discussions. You definitely fit that description.

I've corrected the JPEG disadvantage point to read "every time it's saved" instead of "every time it's viewed". Thanks for catching that. I've also softened my wording just a little on the "I recommend not using JPEG ever" to qualify it as "I recommend not using JPEG ever for texturing". A very minor change, granted, and probably not as much as you personally would probably prefer, but it is how I feel about it, and gosh darn it, it's my article :D.

I do agree with you on the work flow thing if you're planning on putting your stuff on the web. I must admit though, for myself, even for textures I plan on putting on the web, I do make TGA's first, and then export them as JPEG's as an afterthought. I recognize that it's not necessarily the most efficient way to do it, as the JPEG as a texture would likely look perfectly okay; I guess I'm just a stickler for established technique, and for principle.

If I had to justify it rationally I'd probably say that even the minuscule amount of degradation a one-off JPEG texture will have is degradation just the same. Also, if you decide to make changes to it later, it doesn't take a whole lot of edits and resaves before a JPEG begins to show noticeable artifacting. I stand by my trusty TGA for textures. Love the TGA. Bow to the TGA. All the cool kids are using it. :D
_____________________
.

Land now available for rent in Indigo. Low rates. Quiet, low-lag mainland sim with good neighbors. IM me in-world if you're interested.
Rob Triskaidekaphobia
Renegade Time Lord
Join date: 15 Jan 2007
Posts: 2
Thanks!
01-28-2007 09:59
I'm an old (or at least, gracefully aging) graphic artist and even I was baffled by some points in SL, which you've managed to clear up nicely. Many thanks!
Lanny Heaney
Registered User
Join date: 6 Jan 2006
Posts: 26
02-10-2007 23:15
This is a great artical,Fantastic article Chosen! You rock!
_____________________
All Free in Secondlife:
http://www.slworld.info
Free Texture Download:
http://secondlifefree.blogspot.com
zesje Sixgallery
Registered User
Join date: 2 Oct 2006
Posts: 32
size pictures in profile, picks, groups
02-22-2007 04:28
Can anyone tell me in what 3 sizes to save my pictures to upload them for use in profile, picks and groups? And if I do and open them in world will they pop up in the same proportions I saved them instead of distorted pics I get now?
Chosen Few
Alpha Channel Slave
Join date: 16 Jan 2004
Posts: 7,496
02-22-2007 07:24
Great question, Zesje. I'll amend the original post to include that information when I get a chance. I did work it out once, but I don't remember off hand what the numbers are, so I'll have to redo it. The profile pics, the classifieds pics, and the "about land" pics are all odd sizes if I remember correctly.

In the mean time, here's the procedure if you want to figure it out for yourself:
  1. Open your profile..
    Open up your profile, and select the tab with the pic you want to meaure.


  2. Take an OS screenshot.
    In Windows, this is done with ctrl-printscreen. If you're on a Mac, I don't know the command, but there's got to be one. This will copy everything currently on your screen to the OS clipboard.


  3. Paste the screenshot into Photoshop.
    Open Photoshop (or your raster editor of choice), and create a new image. If you're using Photoshop, the new image should automatically have the dimensions of the clipboard image set. In other words, if your screen size is 1024x768, that's what the new image should be. If it's not, then you know the screenshot failed for some reason, in which cahse you should go back to SL, and retake another screenshot. Once you're confident you've got the screenshot in memory, go into Photoshop and hit Edit -> Paste (or simply press ctrl-V) This will paste clipboard contents into the image document. You should now be looking at a picture of your SL desktop in Photoshop.


  4. Measure
    Use the measure tool (it's under the eyedropper, in case you didn't know) to measure the dimensions of the profile picture window, and write them down so you remember (I didn't write it down myself last time, so don't repeat my mistake). Create your image with those same dimensions.


  5. Resize to uploadable dimensions (powers of two).
    Resize your profile image to the nearest power-of-two measurements. SL will do this automatically if you don't do it now, but Photoshop will do a nicer job of it, so it's worthwhile to do it now. The image will stretch/squish to the new canvas dimensions, and then it will unstretch/unsquish when placed in the profile.


  6. Upload the image, and put it in your profile.
    As I said above, your image that had been distorted by resizing it to powers of two will now un-distort when placed in your profile.


There ya go. Seven steps to perfect profiles. Keep in mind, it sounds more complicated than it is. It only takes a minute or two. That having been said, I guess it probably would have been less time consuming just to have done it myself and posted the numbers than to have explained all this, but oh well.

Now that that's out of the way, I'll rant for a quick second. LL, what were you thinking with these goofy pic dimensions? Knowing full well as you do that all images in SL are measured in powers of two, wouldn't it have made sense to have the profile pics follow that same convention? Someone must have run out of beer that day or something.
_____________________
.

Land now available for rent in Indigo. Low rates. Quiet, low-lag mainland sim with good neighbors. IM me in-world if you're interested.
AWM Mars
Scarey Dude :¬)
Join date: 10 Apr 2004
Posts: 3,398
03-05-2007 06:37
Its a pity the choice wasn't wider for graphic formats in SL. Such formats as GIF's which do support alpha and index transparancies (used in the right places) would save rendering of the client and PNG offering 8, 16 and 24 bit versions. Using BMP as a native format is like using a 286 to run SL, so why SL saves in that format defys logic.

Unless you have a powerful system and lots of space to store huge graphics in your cache (most people still have the default value of 20mb cache size which should be changed to a minimum system requirement of 200mb, mine is set at 3gb on a SATA II hard disc) in a VR game also defys logic. The cache size and hard disc speed can greatly reduce the performance of the game along with many other factors.

I hate going to a shop or mall and find myself 'hung' for several minutes waiting for that highly detailed carpet texture to download, or that picture of aunty flo hung on the wall as a 1024x1024 texture, preventing me from walking away from the TP place, even though I have a powerful system (dual core, 2gb DDR, SATA II HD's blahh blahh) and a 8mb connection, only forces me to turn down the graphic details before TPing, and back up after I reach my destination after everything has settled down.

One game I used in the past, allowed you to go to their website and download 'packs' of registered textures uploaded by users in the game, doing so would reduce some of the instant lag experienced. Perhaps LL could make available in the near future.

I do have to comment, why allow textures in a VR game of 1024x1024 when the average users screen is 1024x768 resolution? Even on my 19" LCD with 2048x1200 resolution I can see good detail on textures sized at 512x512? Textures are one of the highest lag offenders in SL, alongside overly primed hair (worst I've seen to date has over 224 prims) and a weapon with over 700!!!
_____________________
*** Politeness is priceless when received, cost nothing to own or give, yet many cannot afford -

Why do you only see typo's AFTER you have clicked submit? **
http://www.wba-advertising.com
http://www.nex-core-mm.com
http://www.eml-entertainments.com
http://www.v-innovate.com
Chosen Few
Alpha Channel Slave
Join date: 16 Jan 2004
Posts: 7,496
03-05-2007 09:50
From: AWM Mars
Its a pity the choice wasn't wider for graphic formats in SL. Such formats as GIF's which do support alpha and index transparancies (used in the right places) would save rendering of the client and PNG offering 8, 16 and 24 bit versions. Using BMP as a native format is like using a 286 to run SL, so why SL saves in that format defys logic.

You seem to hive missed the part in the original post explaining the crucial fact that all textures in SL are JPEG2000's. That's the ONLY format in which SL saves images, and it's way, way, way more advanced and flexible than GIF or PNG. It's a fantastic format. TGA, BMP, and JPEG are simply the source formats that are allowed, from which the JPEG2000's are derived. As soon as you hit the upload button, the conversion to JPEG2000 begins.

From: AWM Mars
Unless you have a powerful system and lots of space to store huge graphics in your cache (most people still have the default value of 20mb cache size which should be changed to a minimum system requirement of 200mb, mine is set at 3gb on a SATA II hard disc) in a VR game also defys logic. The cache size and hard disc speed can greatly reduce the performance of the game along with many other factors.

I'm not sure where you're getting that the default cache size is 20MB. The lowest possible setting is 50MB. The other options are 200MB, 500MB, and 1000MB.

When the First Look changes become part of the standard viewer, I'm sure a lot of people will be thrilled to be able to change their cache size to anything they want, just as you have. For now, you can still fit a hell of a lot of prim descriptions and JPEG2000's within 1000MB.

From: AWM Mars
I hate going to a shop or mall and find myself 'hung' for several minutes waiting for that highly detailed carpet texture to download, or that picture of aunty flo hung on the wall as a 1024x1024 texture, preventing me from walking away from the TP place, even though I have a powerful system (dual core, 2gb DDR, SATA II HD's blahh blahh) and a 8mb connection, only forces me to turn down the graphic details before TPing, and back up after I reach my destination after everything has settled down.

What you're talking about is poor decision making on the part of users, which is what this thread was designed to combat, so thanks for emphasizing that. Yeah, that "Aunty Flo portrait" should definitely be downsized, along with all textures that don't absolutely need to be as big as they currently are, which is most of them.

That's always going to be an inherent problem with user-created environments though. There's really no way around that. You can't force people to educate themselves on how to do it right. All you can do is put the information out there, hope they read it, and that from it they learn to act more responsibly.

From: AWM Mars
One game I used in the past, allowed you to go to their website and download 'packs' of registered textures uploaded by users in the game, doing so would reduce some of the instant lag experienced. Perhaps LL could make available in the near future.

That's a nice thought, but it's really not possible for SL. The world has hundreds of millions of unique objects. I'd guess that among those are at least several hundred thousands unique textures, if not several million, and new ones are being added literally every second. Remember, this is a completely user-created environment, and it's changing all the time. With very few exceptions, there is no static content to pre-cache. That's just not how it works.

From: AWM Mars
I do have to comment, why allow textures in a VR game of 1024x1024 when the average users screen is 1024x768 resolution? Even on my 19" LCD with 2048x1200 resolution I can see good detail on textures sized at 512x512? Textures are one of the highest lag offenders in SL, alongside overly primed hair (worst I've seen to date has over 224 prims) and a weapon with over 700!!!

Your concern about the abuse of large textures is valid, but don't make the mistake of assuming there are no legitimate uses for them. Here are some easy examples that come to mind for responsible use of large textures:
  1. Images with a lot of text.

    Try putting a couple of paragraphs onto a 256x256, and you'll see the results. It's pretty tough to make any significant amount of text legible with so few pixels to work with. Large amounts of letters require large amount of pixels. There's no way around that.



  2. Images that cover objects that are larger than your typical field of view.

    A good example of this would be the flooring inside my USS Defiant model. The carpeting has striping that follows the contours of the corridors. In previous incarnations of the model, I had used a small repeating carpet texture, and I had overlaid additional prims to create the striping. This proved to be inefficient though as I began to approach the limit of my prim allotment. The most prim-efficient way to build the floors was to paint the striping directly onto a handfull of large carpet textures (especially considering that I plan on adding baked lighting in future stages of the build, which would require a ton of extra prims if the texturing were to be kept small). You can only every see a small piece the flooring any one time, depending on what room you're in, but that doesn't mean the texture should be smaller. It has to be large in order to do it's job properly.

    Another, much more simple example, would be the wall of a large building, something with a lot of windows or other details that might make tiling a small texture impractical. When you stand right next to exterior wall of the building, it's far larger than your screen. You'll be seeing just a fraction of the whole texture. It's important that that fraction contain enough detail that the wall still looks convincing. You want to be able to see the grain of the bricks, the shadow each brick casts on the mortar beneath it, etc. You need a large canvas in order to fit all that in.



  3. Images that require a lot of fine detail.

    To use another one of my starships as an example, take a look at the wings of my Klingon Bird of Prey. They're quite large (which also means they fit the above example), they have embossed metallic plates all over them, they show signs of weathering, and they have a brushed metal grain to them. There's no way to include all that with a small texture.

    That particular texture is 1024x1024, and the source PSD required well over 100 layers to create the level of detail I was going for. No way would I do all that work, and then destroy it by downsizing it. Something like that is not an "Aunty Flo portrait".

    For a more hypothetical example, let's say you're doing a replica of the Sistine Chapel. Chances are people are going to zoom in on every fresco and mural, and inspect every last detail up close. For things people will focus in on like that, it makes sense to use textures that are larger than the average screen size, so that there will be no pixelization when they're show fill screen. For something that no one's gonna give a second glance, like maybe the little gold donation plate over in the corner, go as small as possible, but for anything that's likely to be ogled over, don't be afraid to go big.



  4. Groups of small textures can be combined onto a large single "texture sheet".

    This can be a tremendous network traffic saver. Instead of using, say, seixteen individual 256x256's on a build, put all of them onto a single 1024x1024 canvas. While the amount of texture memory will be the same, the amount of network traffic is greatly reduced, as you're only making one call to the asset server to send you a texture instead of sixteen. Also, you get the added benefit that all the images will load at exactly the same time.


  5. Animations.

    Animating textures in SL requires exactly the kind of "sheeting" described in the above example. You need to put all the frames of the animation onto a single sheet. With a 1024x1024 canvas, you can have up to 64 frames at 128x128, or 16 frames at 256x256. Of course, there are many more combinations, but those are the two most common ones, at least for me. If you want any animation that contains more than the tiniest amount of frames, you absolutely need a large canvas.


Those are just a few legit uses for 1024's off the top of my head. There are many more. Again, you're right to be concerned and annoyed when people use large textures in places they shouldn't be, but don't assume there are no good uses for them.

It's really a question of balancing texture resources and prim resources, just as in more traditional applications, it's always a balance between texture resources and poly counts. There's no universal right answer. You have to make the best decisions you can for each and every unique situation. For complex models, sometimes the right answer is bigger textures; sometimes it's more prims. As a competent 3D artist, it's up to you to determine which is the lesser of the two evils, or to put it more positively, the greater of the two efficiencies, for each model.
_____________________
.

Land now available for rent in Indigo. Low rates. Quiet, low-lag mainland sim with good neighbors. IM me in-world if you're interested.
AWM Mars
Scarey Dude :¬)
Join date: 10 Apr 2004
Posts: 3,398
03-06-2007 08:14
I read with interest your response and have no doubt you have a definitive grip of textures in general, however my openning statement was about enlargening the group/format of textures used in SL, not as a direct relationship of what is only available. JPEG2000 isn't the master of all formats available, it is simply only one of two available. The internet would be a relatively a bland place, if it was restricted to only 2 graphic formats. The are many places where other formats triumph over Jpegs and Taga, including the text you spoke of.

With regard to my suggestion of LL releasing packs of textures in a similar way to a previous programme I have not only used, but used to create the worlds used by players, was not perfect, but would ease the current situation.

My suggestion of the default cache size was symbolic, in respect that it is far to small to begin with, by your own statement of their being hundreds of millions of textures in SL. A lot of users I come into contact with suffer lag simply because they don't have either enough cache space to support the textures loading, and or, sufficient free hard disc space to support even the smallest of cache's.

You are correct implying as a designer, you have to create a balance, there should be no need to 'police' or 'enforce' any restrictions, because thats a client side descision by default of individuals being able to control to a point, exactly how much of the hard work a designer would put into their work, that they wish to see, with the exception of prim count.
As a web designer from the bad old days of dial up, the continous balance for quality against useability was foremost. Things have changed and the vast majority have much greater bandwidth, graphic cards, systems... yet we still fight against lag. Effectively, as one element in the jigsaw elevates, so does everything else, leaving you with potentially a level playing feild, just a bit further up the ladder. Some of the 'older' formats are being disgarded, such as GIF's, when its very clear they still have a role to play.
_____________________
*** Politeness is priceless when received, cost nothing to own or give, yet many cannot afford -

Why do you only see typo's AFTER you have clicked submit? **
http://www.wba-advertising.com
http://www.nex-core-mm.com
http://www.eml-entertainments.com
http://www.v-innovate.com
Chosen Few
Alpha Channel Slave
Join date: 16 Jan 2004
Posts: 7,496
03-06-2007 10:55
I'm afraid I still have to disagree with most of your points, AWM.

From: AWM Mars
I read with interest your response and have no doubt you have a definitive grip of textures in general, however my openning statement was about enlargening the group/format of textures used in SL, not as a direct relationship of what is only available. JPEG2000 isn't the master of all formats available, it is simply only one of two available. The internet would be a relatively a bland place, if it was restricted to only 2 graphic formats. The are many places where other formats triumph over Jpegs and Taga, including the text you spoke of.

There can be no question that the range of source formats SL accepts would benefit from some broadening. However, it makes a lot of sense to keep the internal imagery (post upload) all in a single format. They made a good choice in going with JPEG2000. It's arguably the best compressed format available today (and we do need the compression).

I'm not sure what you mean by "one of the two available". To the best of my knowledge, SL has only ever used one format, JPEG2000. In that sense, there's only one "available" format. In the sense that they could have chosen any of the dozens of other image formats in existence either instead of or along with JPEG2000, there are a great many "available". So what did you mean?

You're correct that there are many applications for which TGA and JPEG are not a good choice. However, when it comes to 3D texturing, which is the only application that's relevant here, TGA is the industry standard, and has been for many years. It makes perfect sense for it to be the main format used for creating SL textures. JPEG makes sense also to include since it's so common. BMP's a little bit of a silly choice since it's barely used for anything these days, so I'm not sure why they chose to allow it, but oh well.

In any case, none of those formats are actually used by SL itself. Again, they're just the source. The destination is always JPEG2000, which as I just said, was probably the best single format for LL to have chosen for SL's needs.

As for formats that would be better for text, I assume you mean vector formats. You're correct that they would be ideal, as they have infinite resolution, meaning the text will be legible at any size. If it's too small to read, just zoom in on it a bit, and it will be crystal clear. However, vector texture maps are not part of SL's current architecture. I'm not an expert on the programming of these things, but I'd feel comfortable betting that to include that technology would be a tremendous undertaking (not to mention probably a large performance hit on clients if they were overused since vector math can be computationally expensive). Raster texture mapping has been standard for decades. Vector texture mapping is a relatively new idea.

If and when we ever get the long overdue material shader system that LL said was "coming soon" two years ago, perhaps VTM's could be included with it. That would be great. Don't hold your breath though.

Here is an interesting article on VTM's, by the way, if you're interested.


From: AWM Mars
With regard to my suggestion of LL releasing packs of textures in a similar way to a previous programme I have not only used, but used to create the worlds used by players, was not perfect, but would ease the current situation.

I can't imagine how there could ever be a package big enough to include even the tiniest fraction of all the textures in SL. Even if there were though, would you really want gigabytes of texture data taking up space on your hard drive? I wouldn't. I can wait a few seconds to download that stuff as I go.

You wouldn't think of trying to cache the whole web, right? Well, while SL's not as big as the whole rest of the internet yet, obviously, it is well on it's way. It already contains several orders of magnitude more data than you'd ever want to try to fit on a single hard machine.

From: AWM Mars
My suggestion of the default cache size was symbolic, in respect that it is far to small to begin with, by your own statement of their being hundreds of millions of textures in SL. A lot of users I come into contact with suffer lag simply because they don't have either enough cache space to support the textures loading, and or, sufficient free hard disc space to support even the smallest of cache's.

I'm not sure how grossly misreporting the size of a file directory could be an act of symbolism, but I'll let that go. The rest of your paragraph is far more worthwhile to talk about, I think.

I'm having trouble understanding your point here. You seem to be contradicting yourself. You want a bigger default cache, you want downloadable texture packs that would likely contain terrabytes worth of files, but you recognize that a great many users barely have the hard drive space to accommodate what's already available. It can't work both ways. Should the default be bigger so there will be less downloading, or should it be smaller so it doesn't kill people's already over-strained hard drives?

From: AWM Mars
You are correct implying as a designer, you have to create a balance, there should be no need to 'police' or 'enforce' any restrictions, because thats a client side descision by default of individuals being able to control to a point, exactly how much of the hard work a designer would put into their work, that they wish to see, with the exception of prim count.
As a web designer from the bad old days of dial up, the continous balance for quality against useability was foremost. Things have changed and the vast majority have much greater bandwidth, graphic cards, systems... yet we still fight against lag. Effectively, as one element in the jigsaw elevates, so does everything else, leaving you with potentially a level playing feild, just a bit further up the ladder. Some of the 'older' formats are being disgarded, such as GIF's, when its very clear they still have a role to play.

I don't see how allowing GIF's in SL would combat lag. First, I'm not aware of any 3D application that uses them (it's simply not what they're for), and second, there's really no size benefit whatsoever compared with JPEG2000.

Try this. Take a 1024x1024 RGB image, any image you like, as long as it's a suitable looking image for a texture. That's 3MB of uncompressed pixel data. In Photoshop, hit Save For Web, and take a look at the standard GIF options. You'll see that with the most common options selected, the file will come out somewhere between 300 and 400KB, and it will look like crap (since GIF only allows 256 colors out of the possible 16.8 million the image started with). Now, cancel out of Save For Web, and hit Save As... JPEG2000 (you'll need to have installed the JPEG2000 saver utility from your Photoshop Goodies CD in order to do this). You'll see that you'll be able to get the image as small as about 60KB or so before it looks anywhere near as bad as the GIF.

Again, GIF just isn't meant for this kind of work. If you're a web designer, GIF does have a purpose. If you're a 3D artist, it's not something you ever use.
_____________________
.

Land now available for rent in Indigo. Low rates. Quiet, low-lag mainland sim with good neighbors. IM me in-world if you're interested.
AWM Mars
Scarey Dude :¬)
Join date: 10 Apr 2004
Posts: 3,398
03-07-2007 05:11
I have no wish to elongate this thread for the sake of a difference of opinion. I respect your opinion.... but you do not hold all the answers you protray to have.

My own personal dealings with the internet and RL, has been in the feild of VR and Webdesign for the past 10 years. I... don't have all the answers, but.. there are acceptable standards and tweaks that allow most users to use SL within the minimum standards set by the creators of the programme. The proper use in creating a balance, with regard to cache's which is a 'on the fly' storage facility, coupled with a 'bank' of even basic textures used, would redress SOME of the issues many report. Over liberal use of high quality graphic textures by those that have systems that CAN handle them relatively smoothly, does not take into account those on a lower system, and as SL currently has no way of reducing the quality of those graphics, beyond altering your screen resolution, for those with the minimum standards of system, which still doesn't overcome the file size to be downloaded, leaves little choice. Hence the basis of my statements regarding expanding the available formats for designers.

PNG format with its varied bit rates (8 - 48) goes someways to allow designers to make a choice whether they really want, or need, certain textures to be high quality or not, yet still allowing flexibility. A format sadly overlooked and underutilised in my opinion, that has never been developed to keep pace with some of the more 'trendy' formats.

With regard of your dismissal of the GIF format, I disagree totally. The overheads of the GIF format are much lower than a JPEG, as is the colour depth. Its ability to support both Index and Alpha channels, along with other features. The prolification of Animated GIF's lends itself to a VR environment and indeed I have used GIF's in these ways in VR creations for some years. The 256 colour 'limitation' would still be perfectly adequate for the reproduction of many items such as wood and some fabrics, being creative goes beyond the ability of being able to make something.

To be frank, with a programme like SL, with all its many textures and prims objects, having a small hard disc (hence storage and cache) is ONE of the biggest limitations you can apply to this programme, the same is true for a slow hard disc. Maintaining the Hard Disc (defraging and reducing clutter) is an important discipline. I don't suffer those limitations as I use 3 Hard Discs on my system (2x raid SATA II 180gb and a 400gb, 1x IDE 180gb with 8mb cache) plus the other Hard Discs reachable through my 3 PC network and over 4tb's of internet storage. None of which means I design/create with only my system in mind. I only have this system because I make movies in SL.

I will not respond any further, on the basis of a difference of opinoin.. lets just leave it at that.
_____________________
*** Politeness is priceless when received, cost nothing to own or give, yet many cannot afford -

Why do you only see typo's AFTER you have clicked submit? **
http://www.wba-advertising.com
http://www.nex-core-mm.com
http://www.eml-entertainments.com
http://www.v-innovate.com
Chosen Few
Alpha Channel Slave
Join date: 16 Jan 2004
Posts: 7,496
03-07-2007 08:18
From: AWM Mars
I have no wish to elongate this thread for the sake of a difference of opinion.

That's okay. We can have a discussion. That is what forums are for, after all. At least we're not having anything approaching an ugly argument, and that's good. :)

From: AWM Mars
I respect your opinion.... but you do not hold all the answers you protray to have.

I respect yours as well, and I would also reciprocate the second part of your statement right back at you. You seem to be approaching this from a web design standpoint, and while some of the web's principles can be applied to SL, many can not.

From: AWM Mars
My own personal dealings with the internet and RL, has been in the feild of VR and Webdesign for the past 10 years. I... don't have all the answers, but.. there are acceptable standards and tweaks that allow most users to use SL within the minimum standards set by the creators of the programme. The proper use in creating a balance, with regard to cache's which is a 'on the fly' storage facility, coupled with a 'bank' of even basic textures used, would redress SOME of the issues many report. Over liberal use of high quality graphic textures by those that have systems that CAN handle them relatively smoothly, does not take into account those on a lower system, and as SL currently has no way of reducing the quality of those graphics, beyond altering your screen resolution, for those with the minimum standards of system, which still doesn't overcome the file size to be downloaded, leaves little choice. Hence the basis of my statements regarding expanding the available formats for designers.

The problem you've identified is real, but your proposed solution doesn't hold water. First, there's no such thing as a "basic texture" in SL. You're talking about a world with literally thousands upon thousands of people creating thousands of new textures every single day. How could any "bank" possibly keep up in any significant way? More importantly than that though, as I said earlier, how could anyone possibly store any significant portion of those textures on their own hard drive? You'd be lucky to get 0.001% of the total textures in the world today into one such bank. Tomorrow, that same bank would be even less of a percentage. What you're proposing simply is not possible.

As for expanding the available formats, I fail to see how allowing more types of source files the source files would in any way impact the size of people's downloads FROM the SL servers. There would be benefits to having more freedom in source format choice, sure, but that's absolutely not one of them.

If you're talking about allowing additional types of destination formats, that sound like a formula for disaster. We as users do not and should not have any control over ANYTHING server side. When we create an image, regardless of the format we create it in, it is converted to a single format for server-side storage and client-side viewing. Believe me, you don't want individual users messing with that.

LL wisely chose a format that is versatile, can have an extremely tiny storage size, supports transparency, and has high visual quality. What more could you ask for?

From: AWM Mars
PNG format with its varied bit rates (8 - 48) goes someways to allow designers to make a choice whether they really want, or need, certain textures to be high quality or not, yet still allowing flexibility. A format sadly overlooked and underutilised in my opinion, that has never been developed to keep pace with some of the more 'trendy' formats.

I figured you'd bring up PNG, since you're a web guy. It is a good format, but it's not superior to JPEG2000 for our purposes. While it is slightly more efficient at compressing images that contain relatively few colors, that really isn't a worthwhile benefit when it comes to texturing. It's also slightly faster when it comes to opening very large files, but none of our texture files are large enough for that to come into play. I don't see any way that including it as a server side storage option would improve SL.

By the way, be careful with your numbers and terms. I believe you meant PNG offers a bit depth ranging from 8-48, not bit rate. That range of depth really doesn't help us for what we're doing in SL. 48-bit textures would be insane, and anything below 24 wouldn't look very good. Remember, we're not talking about web pages here. On the 2D web, you can argue that download speed is of greater concern than image quality, but in 3D texturing, photographic quality imagery (24-bit color) is crucial.

In any case, as I said earlier, you don't want individual users messing with server side files. When you upload a file, the system makes all the decisions about how to best convert it for SL's needs, and generally, it does an excellent job. If you think it's bad now, waiting for files that are too large in terms of just pixel counts, imagine what would happen if the compression settings and bit depth were in the hands of individuals. Think about how many people ignorantly make all their textures 32-bit, for example, because they logically assume that "more bits" must be better than "less bits". You really want those people messing with other options?

Look, I'm all for education on this stuff, obviously, and if there were a magic button to push in order to make everyone learn to use the available options responsibly, believe me I'd push it. Since that button doesn't seem to exist though, it's best not to let people mess with anything they don't need to mess with.

From: AWM Mars
With regard of your dismissal of the GIF format, I disagree totally. The overheads of the GIF format are much lower than a JPEG, as is the colour depth. Its ability to support both Index and Alpha channels, along with other features. The prolification of Animated GIF's lends itself to a VR environment and indeed I have used GIF's in these ways in VR creations for some years. The 256 colour 'limitation' would still be perfectly adequate for the reproduction of many items such as wood and some fabrics, being creative goes beyond the ability of being able to make something.

We're gonna have to agree to disagree then. The only thing I'll say is, again, be careful with your terminology. We're not talking about JPEG here; it's JPEG2000. There's a HUGE difference.

From: AWM Mars
To be frank, with a programme like SL, with all its many textures and prims objects, having a small hard disc (hence storage and cache) is ONE of the biggest limitations you can apply to this programme, the same is true for a slow hard disc. Maintaining the Hard Disc (defraging and reducing clutter) is an important discipline. I don't suffer those limitations as I use 3 Hard Discs on my system (2x raid SATA II 180gb and a 400gb, 1x IDE 180gb with 8mb cache) plus the other Hard Discs reachable through my 3 PC network and over 4tb's of internet storage. None of which means I design/create with only my system in mind. I only have this system because I make movies in SL.

No argument there. A good, fast, well-maintained hard drive is extremely important for smooth operating of SL (and of course, everything else). I use three 10,000 RPM high performance hard drives specifically so that SL will run as fast as possible. (All three are SATA II 150GB 16MB cache, two of the three on a RAID stripe, if anyone's wondering. I've been very happy with them so far.)

Speaking of "well-maintained", I'll add for those reading that SL is one of the most brutal programs there is on hard drive health. It will fragment a drive nearly to the point of interoperability relatively quickly if you're not one who defragments on a regular basis.

I recommend everyone get a good degragging utility (I use O&O Defrag; Windows standard defragmenter really blows), and run it as often as possible, like at least once a week.

To give you an idea of just how bad it can get, when I got my new machine, I neglected to install O&O Defrag for about a month, which meant I hadn't been defragging at all that month. All that had been run on the machine in that time period was SL, Photoshop, Maya, and Firefox. When I finally got around to installing and running the O&O program, I found that my C drive was 65% percent fragmented! That's just from one month with SL running every day on a brand new drive. Defrag as often as possible.

From: AWM Mars
I will not respond any further, on the basis of a difference of opinoin.. lets just leave it at that.

That's too bad. This has been a good discussion, I think. Sorry to hear you're stepping away from it.
_____________________
.

Land now available for rent in Indigo. Low rates. Quiet, low-lag mainland sim with good neighbors. IM me in-world if you're interested.
Learjeff Innis
musician & coder
Join date: 27 Nov 2006
Posts: 817
03-07-2007 09:47
Simple answer for profile pics

The profile window is roughly 3x4 shape (the same as a screenshot). Therefore, you can't use any of the standard sizes -- but since this is for use by the client directly, rather than a texture on an object, this doesn't matter.

When cropping photos using MS Picture Manager (weak a program as it may be), I select the 3x4 landscape format and crop.

Later, you can resize the photo if you want, to take less file space, though I don't usually bother. I only have a few of these so it doesn't take much space.

For pixel sizes, this corresponds to these numbers:

CODE

1280 x 1024
1024 x 768
800 x 600
640 x 480
320 x 240
160 x 120


Notice that the second number is always 3/4 of the first.

For a profile pic, there's currently no need to store any more than 160x120, since the window is so small. However, perhaps a future client will be able to display it larger (depending on how the server forwards the image). Since viewing a profile is extremely rare compared to the number of times images are rendered on objects, the efficiency here is not significant, and it would be nice if profile pics were expandable!

Unfortunately, these pics are displayed (when double clicked from inventory, or when giving) as square, causing distortion, because the image storage system is optimized for object textures, not screen shots.

If there's a way to upload an image and have it stored as a photo rather than a texture, I'd love to know about it.
Nefertiti Nefarious
Registered User
Join date: 5 Oct 2006
Posts: 135
Effect of Alpha and Repeats on Video Memory Required?
04-17-2007 10:38
1 - If I have a 512x512 texture that is about 50% alpha ... does that require less video RAM because of the transparency versus colors?

2 - If I have a 512x512 texture that is used on lots of different prims, does it use less video RAM than if those prims each had different textures?
Learjeff Innis
musician & coder
Join date: 27 Nov 2006
Posts: 817
04-17-2007 11:18
Why are you concerned about video RAM?

I don't know how different cards use video RAM, but using alpha doesn't reduce the amount needed. Regardless, SL will run better/faster if you:

a) use alpha when you need it, and not when you don't.

b) use fewer textures when feasible by sharing the same texture among objects, and avoid duplicate textures (using more than one copy of the same texture by uploading the same image multiple times and using different instances for different objects).
1 2 3 4 5