why does SL mess up textures?

Here's a side by side comparison of a texture I made, displayed in my image editing program and in SL. You can see that SL totally ruins the texture. I tried making the texture at various sizes. That didnt seem to help. How can I design textures so SL doesn't mutilate them?



It looks like the texture hasn't fully rezzed yet, but it has.

First thing I would do is check your settings, some settings can make the textures blobby, blurry, or fuzzy depending on your own settings through your PC and SL. This is the most common problem when textures are fuzzy, next to uploading in the wrong sizes and trying to stretch it too much in SL.

Have you tried uploading at 1012x1012 as a test? If it's still looking like that, I'd easily point to the graphics settings.

Heres the texture in SL at 1012x1012:

It doesn't look much better, imho. My graphics settings are all at max. Aren't SL textures stored as lossless JPEG2000? The ruination of my textures looks like JPEG compression artifacts to me. JPEG compression would introduce artifacts like this on images which featured abrupt transitions from one solid color to another solid color. JPEG was designed to display continuous tone photographs, not solid colored line art. However, artifacts like this shouldn't occur with J2, which uses lossless compression. Have the Lindens switched SL's internal image storage format to lossy old JPEG, in order to save storage space (J2 images are larger file sizes)?

SL uses JPG2000, and JPG has always been nasty to hard-edged images like htat.

Also, the quality of the image you see on your prims depends on the memory you have in your graphics card. I almost fell over at the huge jump in quality when I replaced my 128mb video card with a 256mb video card.

You could try softening the edges a bit, a 0.8 to 1.1 gaussian blur - but that's effectively pre-wrecking the image. Making the image larger than you need does sometimes help, depending.

It's resizing the image. Stick with 8, 16, 32, 64, 128, 256, 512 and 1024 per side to avoid the rezise thing. SL is bad, awful at resizing.

I've tried many different sizes for the texture. It still looks like shite in SL. Here's the frustrating thing. If I save the texture back out of SL to my harddrive and look at it, the texture looks good! So, it appears that SL is storing good textures, but displaying shite!

Ya know what...in looking at all my textures displayed in SL, it appears to me that textures that once looked fine look kind of nasty, now. Is it possible that the Lindens have lowered the quality of textures to increase framerate, without informing anyone?

Has anyone else noticed texture degradation? Let me know.

SL loads textures in 3 or 4 stages, starting with a highly compressed B/W version and progressively loading higher-quality versions. It looks like your client simply isn't loading the final, lossless version for some reason. I've never seen any kind of compression artifacts in the final version of a texture, but I have in the intermediate stages. Your pics look just like the intermediate stage that comes right before the final.

I was working with high-detail textures last night and they were showing up just fine for me. I'm fairly certain this is an issue on your end. Sorry I can't offer any advice beyond reinstalling the client.

I agree that the texture corruption looks like textures are not fully loading. I'll try clearing cache and reinstalling if that doesn't help.

At the upgrade about three weeks ago all textures in inventory and on every object in SL with a pixel dimension above 2048 were resized downwards. It was mentioned in the release notes but not otherwise widely promulgated. I think the notes said everything would come down to 1024, but I certainly had lots of 2048's left.

But not for long. At the last update (I think it was) all existing textures in SL were resized again, as necessary to reduce them down to 1024 , in this case quartering the number of pixels, and making lots of stuff look very nasty indeed.

This has badly damaged quite a lot of content creators who have valid reasons for needing really big textures. Books with fine text, movies using texture animation, 360 degree panoramas, and I'm sure lots of others I don't know about. This last stage has also left a lot of neat ordinary stuff looking a bit degraded and rough.

LL implied that the reason for this is because big textures can crash some graphic cards, but it has been found that the problem is one card, an Nvidia, in one computer, the new Intel/Mac desktop. Other applications crash too, and it is now known that the card has a design bug. There is an almost good enough cludge/fix, so these people can actually play, but might crash every 30-40 minutes or so if they encounter big textures.

This is what I have gleaned from other threads - I hope it is about right.

I can't believe all we content creators are being crippled on behalf of a few broken nvidia cards which should surely be replaced anyway.

Many of us believe that the real reason is to cut out all the junk cluttering up the servers in the form of inappropriately large textures, long invited and encouraged by the ridiculously low charge of L$10 irrespective of size, and often done unknowingly/accidentally.

I for one would like to see really big new textures allowed now that the dross has been cleared out, but with an upload charge which rapidly escalates with size, to force people to think carefully, and prevent this waste of server resources growing again.

Even a really big texture, if appropriate for its use, will only be downloaded in fine detail if your camera goes sufficiently close, presumably as the designer intended you to do (definition of appropriate ?). So no-one else will have its data forced upon them, and it harms no-one. In fact, such a big texture is easier on the system, we have good reason to believe, than the several small ones with which it will currently need to be replaced.

So full marks for observation, Paulie. This degradation is grid-wide and, by some of us, deeply deplored.

I suspect that very few people know what has actually happened, or there might be more complaints. I expect most people just have, like you, an uneasy feeling that lots of stuff around them suddenly looks worse, but they dont know why.

I for one, as you can probably tell, am pretty cross. Not often a game can be so substantially downgraded overnight, and for such unclear reasons, and so quietly.

Oh, and Paulie, re-uploading at 1012x1012 was exactly the worst thing to do. It must be exactly 1024 (or 512 etc), or SL messes with it quite badly. And you must best still upload it as a TGA, I believe, despite what it says to the contrary in the documentation.

TGA, 1024x1024.

Surely that picture in your post isn't all of it ? If so it shouldn't look anything like that bad, even with SL doing a really poor resizing. Always resize elsewhere, preferably in Photoshop. It does a much better job. Dont keep resizing, do it once, straight from the original.

Good luck. LL have done a resolution downgrade, but not that much, if that's all of it !

Interesting, Jillian. Seems not to be the case for Macs. My brother and I use identical G4 powerbooks, except I have a 64MB graphice card, and he has the same card with 128MB.

Yet, standing the machines and avis side-by-side, there is no discernible difference in texture res, or frame rates. Or anything else SL related. All we have to do is wait, and every texture seems to click in to its true maximiun resolution, if we are standing near enough. No textures seem to stick a low res, just because of my small graphics memory.

Mind you, from MacOs 10.4 onwards the Mac is a bit of a freak. Everything which appears on the screen is now actually a textured 3-d object, drawn via OpenGl and treated as such by the graphics card.

Weird huh, all 3-d, but just happens to be flattened into 2-d for now.

So in truth, every MacOs 10.4 user always runs the whole SL client on a prim !

Makes one wonder what Apple are planning next? Nothing but a tiny tweak is needed to make the whole desktop spring into full 3-d depth, with things gliding about in proper virtual space.

We can glimpse this when we change user accounts, and we suddenly realise we've been living on the face of a cube. We see it smoothly rotate to bring us the next face, carrying the desktop for the next account.

Very pretty. Is Vista doing something similar, ie defining the desktop as actually 3d, but just incidentally flattened for now ?

I knew about the downsizing of the 2048s, though I wasn't aware it affected so many people. But Chalky, are you saying that the change also affected textures smaller than 2048? You seem to be implying that, since Paulie has tried many different texture sizes under 2048. That and the fact that the pics exhibit significant compression artifacts (you yourself mentioned they look worse than what simple resizing would do) lead me to believe that Paulie is suffering from an unrelated, client-side issue.

He is indeed suffering from an issue entirely unrelated to Chalky's post.

Chalky is just using this thread to post a long, long complaint about the resizing of textures because it bugs him so.

He is in fact exagerrating about the number of people and the content that is affected by this change because in fact, almost no one is and almost no content is. Anyone using a 1024x1024 texture is already pushing the limits, there simply is NO VALID REASON to use a 2048 and his suggestion that there are valid reasons for even bigger textures is just laughable.

Only in the single case of someone runing a monitor at double the average resolution who also wanted to zoom in on the texture so that it filled the entire screen would anyone even be able to notice the difference between a 1024 and a 2048 texture. And the difference then would be minimal at best. When would anyone even need to do this, and for how long? SL is not a static photographic environment, its a moving 3D world.

Why should 99% or more or the users of Second Life suffer trying to load 16 MB textures so that one fool can fill his big expensive screen with a single perfect shot of his own handiwork?

The Lindens have to make choices to make the game work, and 1024 by 1024 as a limit for textures of any kind is a very good choice to make if that is in fact what they have finally done.

People were asking for this for ages.

Uploading process:
1) Resize image down to the closest power of two.
2a) if image type is TGA or BMP, use lossless compression
2b) if image type if JPG, user lossy compression.
3) Upload compressed image.

As an aside, solid color textures compress really well regardless of size; thou they should be made small to save video memory.
JPEG2000 compress the RGB(A) channels separately, if you have an area that is transparent, make the area a solid color in the RGB channels, it will compress better. also if you make the solid transparent color the same as the edge you won't get a halo around your textures as they load.

A few years back I saw a comparison of different JPEG2000 engines; the one that SL uses scored the worst. It has probably improved.

Use the Compress Image feature in the Client Menu (CTRL-ALT-SHIFT-D)
Really, it'll save you 10s of Linden$s!

Brief summary of the below detailed reply to Diane Mechanique, to help most of you decide if you'll bother to look at the detail:

1) Diane, you mistook which of Paulie's posts I was answering, so thought my reply an irrelevant rant whenin fact it directly addressed a precise question she had asked.
2) There are genuine and appropriate uses for big textures, even if you don't comprehend them
3) Appropriate big textures are downloaded by no-one who doesn't need them in the sense that the resolution is required to give sufficient screen detail for the designed purpose at the zoom the user himself has selected. Thus they hurt no-one. This is how we evaluate appropriateness.

______________________________________________________

Full reply begins:
I think you mistake the post I was replying to. It was this one :Makes my reply look a whole lot more appropriate, don't you think, Diane ?

Please, Diane, try to be more tolerant and respectful towards other posters. I suggest that if you don't read their posts carefully, you don't criticise them. In this case you got entirely the wrong end of the stick. You can now see that I never suggested for a moment that Paulie's upload problem was connected with the downsizing.Superficially this does seem correct, doesn't it, in most ordinary applications (even if very rudely phrased) ? But read my post again. I give three examples where bigger textures than 1024 are appropriate and even more efficient than the alternative. Look at each, think about them, and you will see that I am right. If it escapes you why, ask and I will gladly explain.This also is largely wrong if the use is appropriate. Unfortunately it is a widely held misconception. If you knew how this part of SL works you would know that the progressive aspect of Jpeg2000 ensures that no-one downloads much more of a texture than they need to bring it up to their screen resolution. You aren't sent the extra res data unless your camera goes near enough to need it. That's where the word "appropriate" comes in. If the size is genuinely "appropriate" you will only be taking your camera near enough to get the extra res data if you have entered into a situation where you need it for the use for which the object was designed.

For example, if you voluntarily enter one of my big 360 degree panoramas, you will only ever be able to see a small part of the 360 degree texture screen (because it wraps round behind you), and for that (previously single) texture to support your screen resolution and not be horribly blurry it just has to be big. After the cap I will now have to split my single texture into maybe as many as 32 pieces to get the same visual effect (and if necessary I will do it). Placing more demand on the asset server and and the download link (and maybe even the graphics card), not less. (Shall I explain why ?).

So I'm sorry, Diane but
1) my reply directly addressed a question in Paulie's post
2) there are genuine uses for big textures, even if you don't comprehend them
3) appropriate big textures are downloaded by no-one who doesn't need them in the sense that the detail is required to give adequate detail at the zoom the user himself has selected.

You choose astonishing words. "laughable", "fool". Have I unknowingly annoyed you previously in some other context ?

Beatfox, I believe any texture with a maximum pixel dimension of 1024 or less has been left unchanged. No-one but the Lindens know for sure. Maybe next they'll have an algorithm that analyses information content, and resizes further as it sees fit. There must still be lots of 1024's which could better be 512's or even 256's.

Introduce graded upload charges, I say.

We the creators owned and built these shrunken textures. I wonder if they have actually deleted the extra information they have removed, or merely backed it up? Or maybe using TPIP so as simply not to send it? If not deleted, then at least they could give it back to us on request if policy changed, or if technical advances make bigger textures one day become routine in SL.

If its deleted, all that detail on all those objects has gone forever. When we all have 4000x3000 monitors in 2008(9?10?), wouldn't it be nice to have the worthwhile ones back ?

I requested 1012x1012 because the picture at that size would be forced by SL to a compression which in that case, might have *helped* the edges by the forced resizing. While it looks like it did some, it didn't do enough.

Many of my clothes I've been working on have had hard edges and I've found uploading at odd sizes, for god knows what reason, seems to make them work a helluva lot better, than uploading at a standard size.

I don't understand how this feature could save you money, Jesse. On uploading textures ? Please explain - something significant here has obviously escaped me.......

I see ! A way of smoothing/blurring images without using a photoshop filter - ingenious. Have you learned just what it will do, so you can predict the outcome and so use it with confidence ? It doesn't mean you end up with a blurred bigger image, when a crisper smaller one would do ? Does 1012 go up to 1024 or down to 512, does it depend on where they are relative to the halfway point ?

Entirely new suggestion to me - creative mis-sizing - needs some thought....

Aaaaah ! Light bulb goes on !!!! Was Jesse talking to you with the "compress image" suggestion ???

Beginning to make sense.......

lol, I actually have no idea what Jesse is talking about to be sure of.

However, to be totally honest, I hit upon the image forced compression while uploading an odd sized ad, and thought, "Damn, that was really clear!" and played a bit uploading the same ad and found that over sizing it just a bit, seems to shrink it down some and fix the hard edge.

I have NO idea why it works, how it works, just seems to work for me!

Logically, the way I see it, LL forces a downsize, so the initial image upload to the client would be unclear, but upon forcing resize hardens the edges due to the compression.

When I mentioned a "light bulb" realisation, it was because it occurred to me that Jesse might mean you could try alternate blurrings without uploading again by doing this "compress" thing. No need to pay each time you try it a different way.

What you think ?

I've seen such issue before and it happened when I set my nvidia card to "performance" mode as opposed to "quality" in image settings. I dunno if things rendered faster but textures sure looked like crap in SL. Has nothing to do with the actual image compression.

This has been a very helpful thread, and it's saved me some trouble. I uploaded some textures in multiples of 256 pixels and they look really great.

I'd go so far as to urge people to experiment with even smaller textures for builds... 128, 64 even 32 or 16. While not photorealistic, if used consistently and creatively throughout, the effect often looks considerably better in context & more professional to my eyes, not to mention rezzing almost instantly, which is such a relief in these days of lag.