The incredible shrinking textures

So - how many people have noticed that fairly quietly, at the last update, any texture already in your inventory bigger than 2048x2048 has just shrunk to that size ? And that any newly uploaded texture now shrinks to a limit 4 times smaller than that, ie 1024x1024 ?

Does this matter, I hear some of you say. Are there any legitimate uses for textures above that size ?

Darn right there are ! How about animated textures ? 2048sq could store a "movie" of 64 frames each 256x256. Cutting it to 16 frames or 128x128 kills this use dead.

How about landscapes and backdrops and artworks and tapestries actually meant to be "looked at" in detail, rather than used as decoration on prim shapes and objects ?

So what is LL's purpose in rigidly enforcing what was previously merely an injunction to self-restraint ? And will it's purpose be achieved ?

I think the trigger may have been a recent thread (I'll try to find the link) about a Luskwood avatar found to have two huge textures in each tiny eye, which was causing the latest Macs to freeze and crash. Turned out to be a bug in the Nvidia graphics card. Went away when sane eye textures were substituted, but suffered with any other big textures small and close together.

The solution - to quietly reduce the size of tens of thousands of textures across SL - seems a bit drastic - doesn't it ?

But maybe it is attractive because the asset server is crawling along on its knees, and this willgive a small once-only load reduction at a stroke ?.

How did such stupid abuse occur in the first place ? Too easy, I think. Uploading a texture costs the same regardless of size, and no size warnings are given. Isn't this a bit silly ? Surely if big textures were to cost a lot more, only those with a serious need for them would pay? Everyone else would hesitate, think, and use smaller. This charging system had probably produced a large number of unnecessarily-big textures uploaded completely accidentally.

My solution would have been to do a one-off reduction to clear out the old accidents, but then to change the charging structure to prevent accidental use of inappropriate sizes, allowing bigger ones for bigger fees. Not disallow them altogether.

Ah - you say, but that wouldn't help the Mac people. Well, I'm sorry, but if you have a defective graphics card, you can't expect the game to be downgraded to accomodate you.

And anyway, the Linden fix won't really help them either, in the longer term. Everyone who NEEDS bigger images will very soon have them again. Just chop them into several 1024x1024 pieces, upload each, and assemble them in world to produce exactly the same pixel density as before. If they have to go to all that trouble, they might as well go even bigger, so quite likely we will end up with even bigger images than before.

Though not, of course, in an avatar's iris !

A full technical treatment of this topic would be rather complex, involving pixel/steradian in world and on screen, and how LOD is handled in client and graphics card, amount of occlusion in a typical scene at a give visual range etc etc etc.

But at rock-bottom, I think this is a bad decision. It degrades SL capabilities, and it would be better handled by allowing big textures but charging more for them. Forcing us to upload them in bits and stick them back together is tedious, unnecessary, and an over-reaction. With animated textures even this is not possible, and some uses are killed dead.

Sad to see it happen without comment, without debate. Maybe some of you wondered why something of yours suddenly looked blurry, but didn't know why ? This is the explanation.

Any thoughts ?

As I have noticed certain textures loading much faster since the update that used to require up to 45 seconds of waiting... I support the move. Sorry. ^_^

If they never announced the change that's a bit unfortunate - but it may be a good idea to limit textures sizes in the long run. They should communicate the change more clearly though - like if we upload a 2048 texture there should be a warning notice that says it will be reduced so you know what's going on. Another similar issue is that clothing / skin textures will always get reduced to 512x512 when applied to an avatar no matter how big we upload them - but there's no clear message that tells us that in the client. I personally think 512 (final resolution, not working resolution) is all that is needed for clothing but still they should tell us what's going on.

I also like the idea you have of charging more for uploading very large textures and also giving uploaders recommendations to use smaller textures. People who are new to making digital content may not realize at first how much very large textures can tax the system.

I wouldn't exactly call it quiet. It was blogged about nearly 2 weeks ago, and it has been discussed here on the forums as well. I'd strongly advise everyone to subscribe to the Linden Blog RSS feed, so you're always up to date on what's happening. They're still not perfect, of course, but the Lindens have been doing a superb job of relaying information lately. It's up to each of us to take the active step to go ahead and read it.

Anyway, the loss of 2048's is a shame for those of knowledgeable and conscientious enough to have been using them properly, but a bigger shame was probably the amount of moronic mismanagement that was happening with them while they were in place. Every 2048x2048 consumes a whopping 12 or 16 megabytes worth of texture memory. It doesn't take many of those to completely overwhelm a low-end or even a midrange graphics card.

Yeah, I gotta disagree with you on your listed legitimate uses of 2048 textures. I'm sorry, until graphics memory gets a lot bigger and internet throughput higher bandwidth, I cannot support any use of such a huge texture. I appreciate that many people find that limitation annoying, but that's life.

As you even directly mention, there are tricks for getting around texture size limitations. 4 1024 images is better processing-wise than a single 2048. Then there are multitexturing tricks that game artists have been using for years (eg. use alpha transparency to layer a tiled image on top of a single stretched out image.)

Personally, I'm glad to see LL taking action and making firm decisions to alleviate all the lag plaguing SL.

Due to this recent change, I can no longer get nice foot long sausages.

If I could find firm evidence that this is true, then I could perhaps agree with this shrinking of our textures, Johan.

If I fill my view with 4 prims each surfaced with a 1024x1024 texture (case A), I cannot visually tell the difference from a single prim with a matching 2048x2048 texture (case B).

So what are the technical differences betwee case A (after the change) and case B (as it was)?

In case A the asset server finds and fetches 4 textures to send to me, case B just one. Surely B involves less load for the housekeeping, and the change makes things worse for the asset server, not better ?

All textures are of course sent to me as highly compressed jpeg 2000, so the MByte figures someone quoted are not encountered on the link. The quantity of data to be sent in case B will actually be slightly less as most likely the compression will be greater, but in any case, it will never be more. So the new size restriction will load the link a little more, certainly not less.

So where is the problem? Presumably in OpenGL and the graphics card, which needs uncompressed data.

But unless there is a bug in the graphics card (which is what triggered this all off) my understanding is that it doesn't take full resolution data unless it needs it, and I am anyway puzzled if it is the NUMBER of textures which hits the graphics, rather than the total size required to display this part of the picture. Hard to see the logic.

If I felt that this decision to restrict image size was based on hard technical fact, I would be happier.

My guess is that it is not. But rather on social factors. That is - LL do not think it possible to get their residents to judge the appropriate size for an image, and are convinced that we will all continue to upload inappropriately sized images like the idiotic Luskwood avatar's eyes.

I other words, we have to be constrained to little images because we are too irresponsible to be trusted with big ones, and to know when they are genuinely needed.

This is why, until someone points me to a convincing technical explanation, I still feel that the answer is TO CHARGE A LOT MORE FOR BIG IMAGES. This enforces responsible behaviour through the pocket.

Three weeks ago you could upload almost any size you wanted for L$10. Certainly up to 8192x4096. Without even a warning or a protest. This was asking for trouble, and presumably they got it, in the form of lots of people using unnecessarily big textures without thought, and by mistake. Why not, if it costs no more, perhaps they thought ?

There are very few valid uses for an image 8192x4096, but these few are critical and valuable. Like for instance the star field for a scientifically accurate planetarium a friend of mine is working on. How ridiculous that he now has to chop it into pieces, then reassemble it. Let alone the problem of now sliding/overlapping each piece across the adjacent prims. None of which is any problem with one big image. This is just one example.

I am not totally sure that even inappropriately big textures mean bigger downloads, unless you get inappropriately close to them. Isn't this the task of LOD ? Level of Detail ? Doesn't send it all unless you're very close ?

The reason we had a large texture size for our eyes was for animations, as i belive is the primary reason for most all large texture sizes. Obviously no one single static thing needs resolution that high, but if you are trying to encode multiple distinct frames of animation into something, especially sphere mapped somethings, there are valid reasons to use higher resolutions.

At the time we simply assumed that higher resolution was accepted, since the client didn't reject them. Once we were informed of the mac problems we did work to re-adjust our heads to work with a lower rez (1024x1024) texture but that does limit the resolution of each effective frame to 512x512, and when wrapped across a sphere, that leaves something closer to 128x128 to actually use for the eyes themselves... Its not ideal, but if it is what SL needs ta run smoothly, then its what we'll do, no complaints.

are exactly as you described above.

Obviously, you didn't read completely. The texture was for the entire head and the texture animation thereon, not 'each tiny eye'. We don't use prim eyes. The eyes are simply one texture detail of the head. Maybe 5% of it, if that. So we get to use 5% of 25% of the uploaded texture for eye detail. Not very much to work with, after all is said and done.



These "idiotic eyes" were 2048x2048, up from the 1024x1024, giving us a 1024x1024 frame yield instead of a 512x512 frame yield. Each texture is divided into 4 "frames", so your texture yield on a 1024x1024 is 512x512 - The textures were for the entirety of the head, meaning 1/4 of the texture is wrapped around a sphere - for a llSetTextureAnim, meaning each 'effective' texture on these 2048x2048s was 1024x1024 for the entire head which comprises 1/4 of an animation. So, if the face resides on half of that sphere (512x512) we get maybe 256x256 for each complete face detail texture, and maybe 32x32 to 64x64 for each eye.

This is a far cry from the accusation of 2048x2048 for each individual eye, which is an absurd concept and to suggest that we'd attempt such a thing is absolutely beyond the pale ludicrous.

Reducing this to 1024x1024 total, which they did do, provides for a 512x512 texture wrapped around an entire head, which is not very high resolution at all. That 512x512 frame has to be stretched over the entirety of the head; the eyes are only a very small portion of that. As a matter of fact, they look very blocky now. This yields 256x256 for each 'hemisphere and maybe 128x128 for face detail, and 32x32 for each individual eye if we're lucky.



The entire head uses a llSetTextureAnim to do an *animated texture*, so as I said, and as you said, we get 1/4 yield of the uploaded texture for 4 frames. The diminished resolution is an issue we've had to deal with, exactly as you described above.

You say that we used a 2048x2048 for "each tiny eye" which is not only factually untrue, (as the actual eye textures are maybe 1/20th of that) but compounded by the fact that these are texture animations, (comprising the whole face -- one texture for the entirety of the face, not 'each tiny eye') which, even in your opinion, is legitimate large texture use.

as an addendum...

2048x2048 textures are now actually standard in many games and all modern era graphics cards natively handle them without much issue. In openGL by default they will undergo roughly 6x jpeg style compression so they don't actually use *ALL* that terribly much video memory either...

The reason for the specific mac problem was a driver bug relating to 'turbocache' i.e. swapping system memory in and treating it like video ram. The most recent OSX update i believe did resolve this.

Wow, thankyou, Eltee. This is news.

In my opinion texture animation is another APPROPRIATE use for big images. They are needed for longer "movies". Indeed, I am even more surprised that there is any objection to this use.

So no-one at Luskwood was being irresponsible at all. That is good news which had not reached me. Gazing into texture-animated eyes sounds wonderful.

I wonder where this animation is done? Must be in the client, I guess, cant be the server. I wonder if OpenGL has the ability to step through a single texture, or whether the client breaks the texture up and OpenGL handles each part like any other.

Hmmm..... Perhaps it is big ANIMATED textures that give the client a problem? This might explain why I am not convinced of a genuine technical problem with "big-texture versus 4-small-looking-the-same". Maybe there isn't one....just with animations.

And of couse at upload time LL have no way of knowing which will be used for animations.

The plot thickens. On balance, though, I still think it's probably a solution to a behavioural problem, merely masquerading as a necessary technical fix. Though I could well be wrong.

Nah not quite, its kinda a mixed bag really... The speicfic mac problem was a bad pointer/buffer issue with turbocache cards addressing memory wrong when calling up >1024 textures .. thas nothing ta do with animation or anythin else.

The problem LL is more concerned about is long term sustainability and asset control, and it is long term damaging if suddenly the MAJORITY of textures in SL end up significantly higher resolution than they need to be, so they kinda have to clamp it down to stop that from happening.. honestly most static textures are already too big, but in SL its much harder to judge as well...

The free camera means that things will be looked at much much more closely by people than in say doom/quake... if someone wants to look at something specific they will just keep zooming in, so keeping a suitable level of detail, becomes a real juggling act betwen prim allocation, texture use, and texture detail and there is no really 'good' or 'right' answer :/

You are absolutely right, Michi. Now you describe the situation in detail I see that I had quite the wrong end of the stick. No offense was intended, just speaking from inadequate information, I'm afraid. Sorry for that.

Your use as described is in my opinion absolutely appropriate, and the blocky alternative now enforced upon you is one more reason to question this decision.

Unfortunately, quite a lot of detailed technical knowledge is needed to dig out whether the problem is in fact technical, or just inappropriate use clogging up the system.

If, as I suspect, its actually the latter, this is the wrong solution. Change the upload charges, and those who really need big images will dig into their pockets without damaging the running of SL at all.

Except of course for the poor unfortunates with the malfunctioning graphics cards. But I can't concur with damaging the game for so few.

I suspect that LL's past long-term lackadaisical approach to texture uploading charging structure had produced a big overhang of inappropriately large textures, and maybe this was a one-off opportunity to wipe 5 or 10% off the asset servers database. A temporary lifesaver allowing it to keep crawling along for a month or two more while they battle with their scaling problems.

Have you seen the size of the L$ sink represented by upload charges ? Almost stretches credulity.

So is my suspicion wrong, them Eltee ? You see good technical reasons why even one appropriate big texture is harmful to others ?

Or am I right that big textures in appropriate situations do no harm to anyone? The only harm comes from the aggregate weight of masses of inappropriately sized ones ?

After this fresh start/clearing out operation, wouldn't a new charging structure sort this out with less damage than strict size limits ?

You are right from an earlier post in that it is a solution to a 'social' problem masquerading as a technical fix. I.e. there is no 'legitimate' technical reason why 2048 sized textures are unworkable beyond the fact that if they were allowed they would become far too commonplace for things they shouldn be used for and bog down the system and people's clients. i.e. 2048 textured rings in blingchains, etc

Although you're right that it would be slower in terms of sending the data to the client, that wouldn't make much difference and there would be a large difference in processing speed for the client. Basically, splitting up the texture into pieces will allow for more effective swapping of textures into and out of video memory as you look around the scene. For the simplest and most obvious example, if you are looking off to the side and can only see half the scene, only half the image will be filling up space on the graphics card.

I've had many instances on interactive 3D projects I've worked on where the scene initially had one large texture that was running too slow, so we optimized it by cutting it up into smaller chunks that are more manageable for the computer.

This is all irrelevant though considering the more important point that 2048 is just plain too big. These are realtime graphics we're talking about, not a Pixar movie.

To reiterate my feeling...

imo, using a texture larger than 1024 is already irresponsible behavior, so charging more for larger images isn't enforcing responsible behavior, it is giving the okay to irresponsible behavior.

Although admittedly it has been a few months since I last chatted with colleagues about this, I do not know any game artists who consider textures larger than that to be responsible behavior. Even going up to 1024 is reserved for rare special situations (like the sky when all graphics settings are cranked up to max.)

Remember, it only takes a couple 2048 textures to fill up your video memory entirely, and there are lots of other things that need space on the graphics card (like, say, the rendering.) Swapping textures in and out of memory is way too slow to be doing in the middle of rendering a frame.


I'm not sure why you consider this ridiculous. Scientific accuracy is always harder; that's why scientific instruments cost so much. Was your friend expecting it to be easy?

Who here would like to see a proper texture "viewport" feature that would let us smoothly load a portion of a texture and scroll through it, *without* having to download the entire texture?
Surely it's not rocket science to retrieve and send an arbitrary range of data from a file.

btw, this is a great example of what I was getting at when I mentioned how savvy texture artists know how to work around limitations. Here, it's just silly to repeat the pixels for the entire head just to animate the eyes. Put them on separate images and then use alpha transparency to layer the eyes over the face. You're using an extra prim this way, but 1 additional prim is more than made up for by the savings in texture.


um, you consider 512 too little resolution for a head? Damn yo, please consider that not all of us are running supercomputers.

---

Basically, my view is that the distinction between "social" and "technical" reasons for this limitation is a fascetious distinction. Just because the videocard technically allows really huge textures to be loaded doesn't mean you should ever do it.

I simply need textures of 2048 x 2048 pixels in size. I never used anything beyond that size, but I have several huge, wall-high vendors with a lot of rather small text. I did just upload a new one and the text is unreadable (please don't suggest notecards now, I'm a typesetter and layouter and need my fonts to look good, with images in between the text).

I only use textures of that size where it can't be avoided. My shop textures did load pretty fast so far. It will only get slower now when I'm forced to use 4 prims where only one was needed. aside from looking much worse (you always see seams between 2 prim textures) and driving my prim count up. Prevent large textures like that from being wrapped around round or oddly shaped objects if needed, but allow them on flat, square faces please. There's no way I could do with the limitation of 1024 x 1024, sorry.


/Edit: I just read the release notes: ** Existing textures above 1024×1024 will be decoded at 1024×1024 resolution. Checked on my shop - usually I don't look that close at existing vendors, who'd assume that an update ruins their look - and was quite shocked. Here's what the text looks like now:
http://www.succubuscoven.com/vendor.jpg
That's insufficient. The text was clear and readable before. I don't put time and work in this game to see it ruined. Updates are meant to fix bugs and add new features, but not to ruin existing work, one would think. The quality loss due to the second compression is worse enough, but the size decrease simply ruins it. Can I get my upload money back? And have my prim limit raised by factor 4, since I need 4 prims now?

if its sphere mapped remember what i said, 'effective' resolution is quartered, so a 512 spheremap has on its VERY FRONT for eyes roughly the resolution of a 128x128

which like i said, we work with.

Considering my $50 video card handles it with aplomb (6200 passively cooled with 256 megs) im not entirely sure why you need a 'supercomputer' to view things well...

The only real sticklers are 'integrated' video but even that is barely harmed by *REGULAR* textures, even big ones, what hurts integrated video much *MORE* is actually alpha, it hurts it bad, so in general less alpha triangles makes for faster SL

That will not work for our color change eye feature, which already uses alpha. Savvy texture artists know about the alpha sort bug, which has been around since "Tron".

So we would have to give up one of our most popular features (using 1024x1024) to save some vram and and loadtime (512x512+256x512, perhaps, though I believe it'd have to be more like 384x512) - about 40 kilobytes (after J2K and S3TC) of space.

Not to mention it is absolute murder on zoom-out due to LOD.

If you can somehow document an amazing detriment of using (1x1024x1024) vs (1x512x512+1x384x512) [not including anecdotes from people on USRobotics Sportsters and IDT WinChip computers with Monster3D cards] - please do.

But in three years of doing this, I have never seen SL choke on an avatar which contains one 1024x1024 texture. (All of the rest of ours are 512x512 for the upper/lower body [the only res you can do it at, btw] - and 256x256 and 128x128 for other details.) Our color swatches are uploaded at 4x4.

---
Another method would be using two spheres: one 90% cut, one 10% cut, at the same position.

So before you suggest that:

We've tried this. SL does not do it well. Seams always appear. Alpha is an issue. LOD decimates the thing into an ugly mess even in a slight zoom-out. Local/hardware lighting does not cast on it evenly.

Especially if the changed circular cut LOD calculations made it into this upcoming version.

So we use "unreasonable supercomputer" 512x512 frames.



You think 512x512 is excessive for an entire head. Please try it sometime at 256x256, and observe the results.

If you need a "supercomputer" to preload a 1024x1024 texture, you're about three decades behind.

Yes it has been around since tron, but what is it?

Basically alpha stuff when being drawn, ends up being processed in a seperate video card pass from non alpha stuff... this is cause you gotta see behind it so it can't be factored into 'occlusion'

Its pretty much endemic to openGL and basically what happens is that if you have two things, relatively close to eachother, and both alpha, sometimes they will be drawn in the wrong order and the 'back' one will appear infront of the 'front' one.

You can ask me for a lil visual demo object i made long time ago that shows this of pretty well in game.

Its also the trick that makes those weird 'cutout silouette' dance spheres work that you sometimes have seen around (and is also responsable in part, for the inviso-prims)

But suffice to say that alpha things shouldn't be stacked that close together because as soon as the 'center' of the behind one, is 'closer' to you than the center of the infront one, bam, they're drawn backwards

(an thas easy to do by panning the camera to an angle etc)

Ahh.. So THAT'S how Dr. Gibbs and Lora made the orange disappear with the laser..

Just a clarification, I wasn't saying that 512 is too much for a head, I was saying that 512 is a good resolution for a head, and that much more (and the next larger size is already 4 times as much) is excessive. As for the supercomputer comment, note that I'm not just thinking about an ideal situation like a single character standing alone in the middle of an empty scene; if you have multiple characters standing around a dense mall (ie. a typical environment in SL) then those textures add up fast.

At any rate, your screenshots indicate to me that this is mostly a difference of opinion and thus pointless to argue about. As I mentioned above, I accept that this is an online game and not a Pixar movie, and thus assume that there will be a little blurring out of the texture if I zoom way close to details. If you require super crisp lines even when tightly zoomed into the eyes, such as your third image, well clearly your standards are a lot higher than mine.


Not sure what you're asking for, but the little previewer app I'm writing (refer to the straps thread) may be what you need.

What we're saying is that due to there being 4 frames of animation in the texture, a 1024x1024 texture *HAS* available 512 for the head, in each of the different blinking states. To use the actual 512 we would end up with only 256 available for the head, as seen in the *top* picture. The second picture down, which is the one we have always used, is a 1024x1024 texture divided up into 4 frames by 512x512 per frame