Rez times for big textures if only a prtion of it is visible on a prim

That's not mistaken at all. Put simply, when images are compressed as JPEGs they are split up into squares and if two squares are similar then they will both be identical in the resultant file. Zoom into a JPEG and you can see the squares.

You're not mistaken about that impression. You'e absolutely right. JPEG will change the image as it compresses it. Where I think you were a little off was just in the amount.

You are correct that the forest picture would come out bigger when compressed than would the cross picture. The less contrast in the image, the smaller it can compress at a given level of losslessness. To speak in extremes, a picture with just one solid color could theoretically be compressed to almost nothing. All you'd need to reconstruct the image would be knowledge of what is the color in question, and how many pixels it should be applied to, which is obviously a miniscule amount of data. The opposite extreme would be an image where every pixel is a completely unique color. Such an image would not be compressable at all without some degree of loss.

For how that relates to the TGA/JPEG to JP2 discussion, perhaps I should clarify a bit more. Technically, a JP2 created from a lossy JPEG will be marginally smaller than one greated from a lossless TGA, due to the fact that the JPEG will have already lost some contrast and the TGA won't. Assuming we're talking about reasonably high quality JPEG's though, the size difference in the resulting JP2's will be negligible. Strictly speaking there will be a difference, yes, but practically speaking, it's not enough of a difference to be significant. It wouldn't be noticeable.


By the way, to go back to the letter analogy for an explanation of the "loss" in compression, think if it kind of like this. The paper gets folded when it's put into the envelope. When you unfold the letter to read it, you can still recognize it as looking mostly like it did originally, but the folds will always be there. The damage, even if it's minor, has been done and it can't be undone. The "image" has been changed by its packaging.

If you're using a large business size envelope, you won't need to do much folding, so the letter's look won't be changed much. Most of the information will be retained. If you're using a tiny little mini envelope, like maybe the little 2" ones used for wedding favors, you'd have to fold the paper many times, and the damage to the look of the letter would be much more severe.

However, no matter how many times you fold the paper, even if you crumple it up into a little ball and stomp on it, it will always be 8 1/2 x 11 when you unfold it to read it. The only difference is how little or how much cosmetic damage you've done to it. If you've given it a lot of folds, some of the words might not be legible anymore. If you've crumpled it up and stomped it flat, the whole thing might be a smeared, unrecognizable mess. It's still gonna unfold to 8 1/2 x 11 though every time.

Now let's take it a step further. Picture a letter that's been crumpled and uncrumpled a few times sitting along side an identical letter that's printed on pristine, undamaged paper. Pretend the crumpled one says JPEG on the back, and the undamaged one says TGA. Now let's say you want to put the letters into two identical envelopes, both of which have JPEG2000 written on them.

The letter that's been crumpled will fit into the envelope a little bit more easily than the fresh one since it's already been folded, but each new fold you add as you put it in will damage it a little bit more. The pristine letter will also fit, but since it's never been folded before, it's still got some spring to it, which means it will end up pushing out on the inside of the envelope a bit more than the crumpled one would. As a result, the envelope with the fresh letter in it will bulge just a little bit more than will the one with the pre-crumpled letter. The bulge really isn't gonna be enough to be noticeable, but if you really set your mind to it, you would be able to tell which package is which, if you really, really wanted to.

Since most people will never ever look closely enough at the two envelopes to notice the difference, practically speaking, there is no difference. In the strictest sense, the two are indeed sized a little bit differently, but for all common intents and purposes, they are the same size.

While the size difference is negligible, the cosmetic difference is anything but. Open up the fresh letter, and it will be almost as good as new. Open the crumpled one, and it will be evident that it's been through a war or two in its day.

The bottom line is the TGA and the JPEG will be practically identical when packaged as JPEG2000's, but when opened as images, the TGA will look significantly better than the JPEG.




You got it.

Guys, I don't want to step on any toes here. I'm new to SL and I don't totally understand how SL uses images, etc. However, I do work in the graphic industry and deal with images on a daily basis.

Ever since digital photography has been around there has a been a debate amongst professionals about whether they should use RAW file formats like photoshop source, tiff source, etc. or whether compressed formats like jpeg were good enough. The debate still continues, because to the most of us, a compressed image when compared side by side with the same image from raw format are VERY hard to distinguish from one another. It really takes a trained eye. And for people who are highly trained in image qualities, they simply have a hard time settling for less than the best an image can be. However, the vast majority of us don't even see what they are talking about.

Jpg can be used wisely and IS used by RL professionals every day. So, there really isn't a need to worry about about the image quality compared to tga. Surely there is some loss, but we're talking something so miniscule that less than 1% of you will notice it and that's only if it's pointed out to you.




Granted, I do not know how things work on the server side at Linden Labs. But what you guys are saying is that Linden Labs stores our textures in the format we upload them and converts them to JPEG2000 every time the texture is called for in world. You'd think that they'd convert ALL images to JPEG2000 upon upload and store them that way.

As for speed, I find it hard to believe that it takes longer to display a jpg file than a targa file. I understand that decompression needs to take place, but there is also some image 'interpretation' for targa files. In addition, the average 512x512 targa file on my system seems to take about 1 meg of memory whereas the average 512x512 jpeg is about 60k. That's a huge difference. Surely the jpeg decompression can be done within the extra amount of time it takes to pull a targa file off the hard drive!!!

Like I said, I'm new at this, but I do know that there are many people in the digital industry that simply won't accept jpg because it does compromise a tiny bit of image quality. However, there are also many others who use it every day. If used wisely, the difference is miniscule.

Thanks 4seti for directing me to this thread. Lord knows we've had these discussions on textures into the wee hours.


My background is in website graphic design so Make Web Ready is like my right hand - I'm so used to optimizing graphics that to NOT do it seems like a mortal sin. And obviously I've also been uploading everything into SL as an optimized .jpg file (unless I need transparency).

My biggest concern is loading times for my textures in SL. And again, that crazy JPG2000 conversion really throws a wrench in my logic that a smaller file size = faster SL loading times.

What I'm understanding is that since the file is always converted to JPG2000 anyway, there's no need to optimize the file before uploading to SL - whatever load time I save will be miniscule compared to the quality loss?

Agreed, mostly, but my point is why bother with JPEG at all when there's absolutely no benefit? The benefit of using it in something like a camera is that you can fit more pictures onto a memory card. The benefit of using it on the web is that files will travel across the internet faster. There is no benefit whatsoever to using it in SL. All you do is noticeably lower your image quality without noticeably reducing your file size. There's simply no point.

Additionally, there are a couple of important factors you failed to mention. First, most people do NOT use JPEG "wisely" as you put it. It's a delicate balancing act to find the optimal tradeoff between quality and size and it's different for each and every image. Most people just pick one setting and stick with it. As a result, half their files are ugly, and the other half are too big.

Second, every time a JPEG is opened and closed, it loses a little bit more. That "miniscule loss", as you put it, is like compound interest. It's a little bit the first time, a little bit more the second time, and then before you know it it's huge. While photographers may choose to use JPEG in the field as a first generation storage solution, no self respecting professional will ever open those JPEG's more than once. The first thing they'll do when they plug that camera into the computer is grab all the files and batch convert them to TIFF.

Keep in mind, by the way, that a JPEG uploaded to SL is compressed not just once but twice. As soon as the JPEG itself is opened, it's already lost some quality, and then when it's recompressed to JP2 it loses a little more. JP2 is optionally lossless, yes, but I don't think it's optimized that way in SL. You can definitely see quality differences once textures have been uploaded, especially at zoom. Those differences are increased by an order of magnitude when the source wasn't clean to begin with.

Another important thing to realize is that just because only "1%" of people might be able to consciously define the loss of quality doesn't mean the other 99 aren't aware of it on some level. People don't stare at the Mona Lisa because they can consciously define why it's beautiful. They just look at it and they feel it. Sure, the trained eye can point out all the golded rectangles, the definitive subtlties of the coloring, etc, but the layman just looks at it and FEELS that it's right.

While we're on the subject, it's worthy of note, by the way, that not even DaVinci himself was able to define why his paintings were masterpieces, or what made one image "higher quality" than the next. He just painted what felt right to him. It was only later that so called experts went back and assigned definitions to everything he (and other masters) did.

So, while yes it takes a trained eye to verbally point out what's different about 2 nearly identical images, anyone and everyone knows which one feels better, instantly. I won't risk lessening that feeling just for an inconsequntial difference in file size, ever.


No one's saying that at all. I'm not sure where you got the impression that anyone was. Yes, images are converted at the time they are uploaded, and yes, they are stored on the server as JPEG2000. That in no way negates what I said about the system having to read the file before it can compress it though. What gets compressed to create the JP2 is the actual bitmap, not simply the ones and zeros of the file code. Otherwise, it would end up as something like a ZIP file, and nothing like a JP2.


First, don't confuse hard drive space with texture memory. Yes, a 512x512 32-bit TGA will be always one megabyte in size, and yes that same image as a JPEG could be compressed into a 60KB package for storage purposes, but when you open it to view it, it is absolutely consuming the same amount of living texture memory as the TGA. Pixels are pixels.

As for speed of opening the files, that's debatable. It all depends where the bottleneck is. If we're talking about on the web, then clearly the JPEG would win since the bottleneck is transfer speed. If we're talking about opening a file from the local hard drive, then it's much harder to define. The TGA would take more time to pull from the hard drive into RAM, but the JPEG has to have a lot of math applied to it before it can open. It really could go either way. Ultimately though, we're talking about microseconds, so does it even matter?


Agreed. But once again, why settle for a quality reduction, even a miniscule one, when there's absoultely no reason to do it?

I've trained a few people in web design - four of them were print designers, and while dealing with them I was constantly reminded about the vastly different mind-sets that exist in the digital image world. Many things that are true in print are evil poison on the web, and vice versa.

I think the whole "JPG as 99.9% acceptable" debate is an example of this. Professional digital photographers, for example, take pictures at resolutions of a few thousand pixels per side. They also tend to take picture of "natural" images (landscapes, people, etc). JPG is a truly incredible compression scheme - specifically designed to handle this type of image. JPG a 4000x3000 mountain view, and no-one is gonna see the difference.

However - give JPG a lower rez image - of something hand drawn (or rendered by a cad program, for example) - and the quality loss is immediately apparent. This is more the realm of SL textures. Regular, "artificial", low rez images - exactly the opposite of JPGs intended use.

By analogy - if you are in a region that uses GSM cellular phones - have you ever noticed how bad on-hold music sounds over a mobile? GSM compression was designed for the human voice - and can compress such a source incredibly, reliably, and with no perceptible quality loss - but... give it a violin and some drums, and watch it fall apart.

In summary - often the hard-and-fast rules learned in some sub-genres of an industry need to be "unlearned" in others. When it comes to SL, in my mind TGA is the only way to go.

That was an awesome reply, Ben. My rant on this subject was a mile long, and your 5 paragraphs said it 10 times better. Bravo.

yes becuase uploading a texure of black and white text is soo much better @ 3mb rather than 300kb... there is a line, yes tga is better, but it depends on what your making...

Small text signs jpg
crappy little icons jpg
large animation sheets jpg (or your gonna be sending a 10+mb file up)
or my favorite, i made it in ms paint @ 1024x1024 and it still looks like dirt, go jpg who cares lol every little bit that can be conserved helps

Reasons...
#1. Disk space. 1 meg targa vs. 60K jpeg. Of course, in today's world of 400 gig drives, who cares, it's miniscule.
#2. Upload time. Surely uploading the 1 meg targa file takes longer, which surely compensates for any extra time needed to uppack a jpeg file.
#3. For product images/vendor signs slboutique only accepts jpegs.

#1 and 2 are no big deal. #3 is the kicker for me, on promo/vendor files. I upload all my clothing textures as targas and all my promo/vendor signs as jpeg. It's just easier that way because of slboutique.

I do agree with all you've said, Chosen and Ben, but In my humble opinion, and seeing images in SL, I still don't think the jpeg file is really taking that big of a hit in quality.

I haven't noticed any image loss on my jpegs, and I'm picky. Of course, we're not dealing with museum like standards in SL either.

Sorry if this seems like a mountain out of a molehill issue.

Your image is converted to JPEG2000 before upload, the SL client does it.

Anyhow, another massive source of client side lag is the sheer number of polygons ("drawing units" some prim shapes produce. I'm often having enough video memory for textures yet crawl at 1FPS around people who use twisted tori.

So kids, use small textures and don't wear prim hair

You seem to be missing the point. Everything on the SL servers is JPEG2000. A JPEG2000 sourced from a JPEG is the same size as one sourced from a TGA or BMP or PSD or any other format. After an image has been uploaded, it's not gonna be a question of 3MB vs. 300KB. It'll be more like 200KB vs. 199.999KB.

And that's just storage space, by the way. As far as live texture memory goes, file size is complete irrelevent. It's the pixel count and bit depth that matter. Your system won't perform any better having a hundred JPEG's onscreen than it would having a hundred 24-bit TGA's onscreen. It'll just look worse.

The only speed difference with regard to SL is in the time it takes to upload the file the first time. After that first upload, the source format becomes moot. The largest image size SL will allow is 1024x1024 which means the maximum source file size is 4MB with transparency, and 3MB without. Since we're all on broadband, that's an upload time of just a few seconds. Sure, the same non-transparent image as a JPEG would probably be just a couple hundred KB, so it'll upload a lot faster that first time, but again, once the SL server gets ahold of it and changes it to JPEG2000, it's gonna be a little bit smaller than that couple hundred KB whether it came from a JPEG or a TGA, and it's gonna use the same amount of texture memory no matter what format it is.


Server side disk space is irrelevant, since as we've discussed numerous times now, the JPEG2000's will have virtually identical file sizes, no matter what format they were sourced from. If you're talking about the disk space of the person who created the image, well then you've got a point, but nobody uses JPEG for archival purposes anyway. Layered TIFF's and/or PSD's should always saved in addition to flattened copies. If someone's really more concerned about saving space on their own storage drive than they are about archival quality, frankly they shouldn't be in the digital arts. That may sound harsh, but it's true.


You're talking about a one-time wait of a second or two vs. a pemanent loss of quaility. Sure the JPEG will upload faster than the TGA, but once that one-time task has been performed, there is no ongoing speed difference. Every time you view the texture in SL, you're seeing the JP2 that's been saved on the server. The original file you uploaded is gone.


That's because SL Boutique is a website. JPEG is the format of choice for the web. That's what it's for. What it's not for is 3D graphics.


How about using TGA versions on your inworld signs so they look as good as they can, and then using JPEG versions on your web stuff? That is the way it's meant to be, afterall.


Whether it's a big hit or a small hit, quality loss can only be justified if there's some other benefit that outweighs it. On the web, that benefit is obvious, speed. The aesthetic of anything and everything on the web is EXTREMELY secondary to its download speed. On the web, every fraction of a second counts.

In SL, however, there is no difference in download speed since all images are JP2, regardless of from what format they were sourced. Therefore there is absolutely no point whatsoever in taking ANY quality hit, great or small. There's simply nothing to gain and plenty to lose. Seems like a no-brainer to me.



Not dealing with museum-like standards? Says who? I know you don't mean that as an insult, but I am a bit offended by the comment, none the less.

Tell the builders of places like ChinaTown and Midnight City that they're not producing "museum quality" work. Tell someone like Chip Midnight that his skins are not "museum quality". Hell, Chip's stuff looks better than what's on 99% of all the video game characters in the world, and the guys who make those characters get paid high fives to mid six figures that kind of quality.


Not all. With the acception of that last comment, which I'm sure you didn't mean the way it sounded, this has been an enjoyable discussion. As I've said repeatedly, my mission here is to do my part to help make SL look as good as possible. Discussions like this are an important part of that.

First off I also bow to Chosen's wisdom and haven't seen anything I disagree with.

A couple of things I would add to the conversation...

Consider a simple statistic:
800x600, bare minimum anymore.
1024x768, fairly common if you're on 15" (or getting old <sigh>
1152x864, my preferred size on a 17" (an old throwback to Sun machines)
1280x1024, here's the first resolution that could *theoretically* display a full 1kx1k image.
1600x1200, generally insane for gameplay but it's out there.
plenty of other oddballs out there... lots of 16:9 ratio stuff for watching movies, etc. but most dont equal or excede the 1024 vertical.

So, most of the screen resolutions out there can't or can barely display a 1024x1024 texture all at once. Plus we have LOD or Level of Detail in use which calculates how big of a downsampled version you need to actually see depending on how close the camera is to the object. so not only do you have JP2 compression at work but LOD determined downsampling coming into play.

I know the initial question was whether it would help with load time but since the graphic card still deals with the entire image even though a prim may not show it all you aren't gaining as much detail as you are saving in load time. LOD may determine you need the 256x256 downsample on all the prims which means you'll only see a 64x64 equivalent on each prim face.

So to sum up:

Save *everything* to be uploaded to SL as Targa.

Save 32bit *only* if you need alpha. Save 24bit for everything else.

Save promotional materials for web publishing as JPG. (but hey, crank up the jpg quality,
nobody cares... were all on high-speed anyway right?)

Get used to working in powers of 2, the web doesn't care but 3D apps do. (yes many cards now support non- 2^n textures but they *do* have to work harder for it)

Powers of 2 dont have to be square; 512x128 is a perfectly valid size for a texture.

Feel free to work in higher rez then downsize your final upload copy. BiCubic resampling is way cleaner than LOD.


L8r,
UU

Somehow related question - do you folks have advice how to deal with the following problem:

Texture sizes are in powers of two (if not, SL will resize it before upload).
Repeat/offset parameters work with decimal numbers and have limited precision.

I've been bitten by it recently trying to do 'animation' texture. Let's say I'm doing 100 frames on single texture (in 10x10 grid) and want to show only one at a time.

So on 512x512 texture that would mean 51.2 pixels per frame. Which is not good.
Or, I make the frame size some number that can divide 512. If I use 32 pixels for frame I get whole pixels. But, now the texture has 16x16 frames instead of 10x10. Instead of using numbers like 0.1 for repeat, you have to use numbers like 0.0625. And the precision of the texture parameters is not big enough to hold the whole number, so you get repeat of 0.063 or something and have misaligned pixels again (it gets worse with 32x32 grid etc).

So either I have whole pixels when creating the texture in photoshop or when displaying the texture on a prim. I haven't figured out a way to have both. Should I use bigger textures to try to minimize this 'repeat drift' ?

Good stuff, Upshaw. Thanks for adding this to the discussion.


Great questions, Candide. You've hit on one of SL's little "rock and a hard place" type problems. There will be benefits and drawbacks to every solution. I'll take your questions one at a time and tell you how I normally deal with this issue.



The answer here is that while yes, the numbers you can enter into the editor have horrible rounding issues, especially in 1.7, numbers generated by scripts do not seem to. Scripts are very precise as far as I can tell. So, if you tell your animation script that your texture sheet is 10x10, it will show 1/100 of the sheet for each frame, regardless of texture size.

I should probably state a little disclaimer, which is that I am an no way an expert on the inner workings of LSL, but I do know what I see. Visual evidence suggests that scripts can do division, while the editor is limited soully to multiplication. For example, you could tell the animation script your canvas is 3x3 frames, and it will actually divide the image by 3 in each direction out to a pretty long decimal. The best you could do with the editor would be to multiply by .33, which kind of blows.



I usually use frame configurations that divide evenly into the canvas size, and then tell the script to ignore any extra ones. For example, if I remember correctly, the animation of the spinning Earth with the SL logo in front of it that I did for Help Island uses 15 frames. I split the canvas into 16, and set the script to only play 1-15.

To go with your example of 100 frames, the first thing I'd ask myself is do I really absolutely need 100 frames. Going with a frame size of 64x64 would yeild much cleaner results. The configuration would be 8x8 instead of 10x10, so you'd end up with 64 frames instead of 100, but 64 frames is still a VERY long animation by SL standards.

If I really did need 100 frames though, then this would be one of the rare occasions where I'd increase the canvas size to 512x1024, and go with a frame configuration of 8x16 for a total of 128 frames. I'd then set the script to ignore 28 of the frames.

Another option, by the way, is to start with a canvas size of 500x500 in Photoshop, and then resize it to 512 as a final step before upload. It won't be as clean, so I don't really recommend it, but it is simple.


Already answered above, but I'll repeat once again. The animation script is lightyears ahead of the editor, precision-wise. Don't worry about the math. Just tell the script how many frames you've got and it will do the rest.


As I said above, going with a larger texture is one way of making sure you've got enough frames, but before making that decision you should always ask yourself if it's really worth it. The bigger the texture, the more lag it creates for everyone, even if only a portion of it is showing at the moment. My first answer is always if you can go smaller, go smaller. If you absolutely need to go bigger, then do it, but do it sparingly.

Once again, though, don't worry about the "repeat drift" as you put it. Let the script do it's job. The editor sucks, but the script works just great.

Hope this helped.

Chosen is right about the mysteries of LSL. Again it's really only possible for the animation script to judge by eye, but LSL uses floats to 7dp which means it will be exactly right for up to more frames than you can reasonably use - a 32X32 (smallest image size possible) image could be accurately (mathematically) divided into 2048 X 2048 frames - although it would be very dull at 1/64th of a pixel per frame!

The suggested approach to divide the animation up so that there are frames of a nice size (e.g. 128 frames as say 8X16 on a 512 X 1024 grid and ignore the last 28 frames) is also probably the smartest combination of the two.

The script you want will look a bit like:

default {
    state_entry() {
        llSetTextureAnim(ANIM_ON | LOOP, ALL_SIDES, 8, 16, 0, 99, 0.5);
    }
}

Feel free to use and amend this: I took it from the llSetTextureAnim wiki page.

The top line reads:

llSetTextureAnim(integer mode, integer side, integer x_frames, integer y_frames, float start, float length, float rate);

So mode is on, smooth and looped (they're bitwise OR'ed together - that's the | using technical terms). You can choose on or off, variation around smooth, looped, rotating etc. textures with the mode.

You can animate different sides differently if you want to.

x_frames and y_frames tells the script how many frames there are along and down respectively, and start and end tell it the first and last (so you can have 128 frames and only use 0-99, remember it will start with frame 0 not 1! Also remember that setting the final frame to 0 will actually animate them all, not just display the first frame).

Rate is how fast - the time each frame lasts in seconds.

People might at this point wonder why the start and length are floats (numbers with decimal points) - this is because for a rotating texture the start and length are the angles of the rotation in radians - so a full rotation will use 0 to 2*pi or about 6.28318 which needs to be a number with decimal points pretty obviously.

This isn't really the place for a detailed discussion of the scripting call, but the wiki gives you more and this should be enough to help you use the script a bit until you want to see and do more with it. There are debates about how this works with the other scripting calls to scale textures, but generally this will overwrite them although confusingly all the other calls will compile in the script if you mix them up. The compiler checks that they're all legal statements, NOT if they're smart and work properly together.

Thanks for the good info, Eloise. Just wanted to add one comment, which is that for framed animation, I would remove the SMOOTH command. With SMOOTH in the mix, you'll see the texture physically slide from frame to frame. Without SMOOTH, it will go from one frame to the next instantly without any visible transition.

Thanks Chosen, you're right, SMOOTH | will make it slide (like water does) and not flick like a stop frame animation. Serves me right for cutting and pasting whilst the caffeine levels were too low.

I've amended the snippet so it doesn't have smooth in it in any more.

Well I'm using llSetTextureAnim to basically replace llOffsetTexture and I'm definitely seeing pixel leakage between frames - especially when using very small frames, like 8px high. The vertical offset is sometimes off one pixel (in either direction), and since I'm stretching those 8px over the whole surface it's very visible.

I gotta ask, why would you want an entire prim to only be covered by 8 pixels? I'd be more inclined to believe the "leakage" you're seeing is an artifact of the extreme upsampling SL needs to do in order to make those 8 pixles fill your screen than I would that the animation isn't framing right.

The smallest single texture size SL allows is 32x32, and there's probably a reason for that. I would suggest making sure your frames arealways bigger than that.

Imagine a vertical line that is moving left or right, sort of like the text cursor. That's what I'm trying to display. So those stretched pixels just make one vertical line. I have 1x128 animation frames in the texture, each frame is 128px wide and 8px high. The texture looks like this

.|
  |
   |
    |
     |
      |
 etc

The prim that is displaying the texture is wide but not tall, I ended up with such frames because I need good horizonal resolution. This way I can have 128 different line locations since the line is only 1px wide. I could have 256 locations if I made each frame only 4px high, but then then the artefacts become even more visible. All this nonsense is just because llOffsetTexture is so slow and sim lagging.

I guess that makes sense as to the why.

It's nice to see definitive proof that it's not working as I'd expect.

Thinking about it I guess that means it's doing the 1/n part first and 1/128 works out to be 0.0078125 which is 7dp long, BUT any rounding on it in the last place will give you the 1 pixel offset you were observing. I guess that might mean 64X64, or for you 2X64 might be better options. In that case my earlier statement about 1/64th of a pixel and 2048X2048 is wrong - if we use 1/64 as our limit you're still looking at 64X64 frames obviously, and 1/2 pixel per frame for a 32X32 texture.

It could also be, as Chosen suggests an artefact of blowing the texture up, or a combination of these factors.

Pardon me for resurrecting this thread, but I was searching for guidance on texture size, and Chosen Few's posts here answered most of my questions. I'm uploading 256x256 TGAs for vendors, but the images are pretty simple, and like everyone else I'd like to minimize lag. So my question is: is there a *minimum* texture size? Could I upload 128x128?

I guess I'll just try and see, but I thought I'd post my question in case anyone has any wisdom to bring to bear.

Edit: after further searching here, I found a thread that mentions a minimum texture size of 32x32. So I'll definitely give 128x128 a try.

8 16 32 64 128 256 512 1024 and any combination, are the magic numbers

thats why pixel count is important

a 512x128 has the same amount of pixels as a 256x256

I just wanted to chime in...I read several pages deep, and wanted to share my ethic and method.

Firstly, I use TGA...always. And of course, if the texture doesn't require a transparent effect, I'll go with 24bit.

Secondly, I'll be completely honest...I use as large a texture as I can. Unless I'm texturing a thimble, I use 512 as the max dimension. However, there are rare occasions that I will even use a 1024 max texture. How dare me! I know...but believe me, there are certain bits of my items that require the high definition...and I give it to them...and believe me, it makes a huge difference.

Now, a lot of you may think people like me are the folks slowing the grid/sim down. But I can safely say, I've reeeeally gone over the pros and cons--both from a sellers point of view, and a consumer's point of view. I've been a cg artist for over a dozen years, and in my experience and judgment, I've chosen to tilt on the higher rez side of texture art. I HATE blurry textures...on my creations, and other peoples' creations. If I have to use a 1024 texture to clear up an image, I'll do it. Don't misunderstand me...these are rare occurrences, but they are definitely there.

I will bring up, if you searched through my studio, you'd find a bit more 1024 textures than there needs to be...I'm still lazily going through all of my build...it takes time. When I first joined SL in 2005, I used a lot more 1024 textures...now'adays, I use them sparingly.

I just think a higher quality end-product is more important than a few FPS difference. I mean, I'm using a bloody P3 processor...if I don't mind walking around my high prim, high quality studio...then I don't imagine a consumer will. I've never heard one complaint, and I sell quite a bit of merchandise. I think, as long as you don't have a ton of 1024 textures and dirty scripts in your parcel/sim, the average computer will run it well enough to enjoy your experience. I mean, I enjoy the hell out of SL, and I get an average of 6-10FPS at all times.

I think people should spend more time creating quality textures, and less time worrying about how to optimize them. Take some of that QA energy, and apply it to tactile practice in your craft--people will be much more impressed with a skillful texture, then with a fast loading 256X256 mega panel.

I know I may not have an orthodox view of things...but personally, I think I've found a nice balance of quality and optimization--something more people should do. As long as you don't go ballistic with massive textures, focus more on quality end-product and not lightning-fast loading times.

Bad, low quality texturing is something that plagues many many builds and products out there. I'm not judging anyone, or being elitist...I'm simply saying I'm much more inclined to spend more time letting textures load in a quality build...then I am hanging out in a boring, blurry, default texture pack build.

Which brings me to custom texturing...far too many people don't create their own textures. I think people need to realize that in really high quality work, each texture on each face is picked specifically on many occasions. Hand-painted to incorporate decals, shadows, specularity, pseudo bump mapping, and text. If you toss pre-made textures on all your objects, they are going to appear boring and humdrum. But if you take the time to paint in key shadows and highlights, or personalize each texture to that particular object, you'll garner a lot more attention. Anyway...just saying...

I love you all. I'll STFU now. Cheers.

lol, still the occasional thread I'm subscribed to bringing me back... have they rolled out Mono yet, might log in in-world to have a play if they have.

Anyway, Michael; a suggestion that came to me: if you're producing items for others and don't know the context the item's going to be put in (i.e. what resolution you're going to want the textures), how about doing them at multiple resolutions with a script to switch them? To be honest, high-res textures are totally correct in the long term IIRC; since the client is intended to load the progressive steps of the image as needed and only display the most reasonable one when rendering. Of course, the chances of all that happening are probably pretty slim.