The incredible shrinking textures

Michi identifies the third picture as the one you guys were using. Oh well, whatever.

though it will not be available for quite some time unfortunately i think, is to allow shaders. Using shaders you can create much additional detail within a rather small texture (say 256x256) but then add 'surface detail' to it mathematically when its being drawn. This allows even low resolution textures to look quite good and is actually believe it or not a *very* old trick (it dates back to the original voodoo card whos glide library allowed 'detail' textures to be applied (when looked at closely in addition to the normal surface texture when seen from further away) and the game unreal).

This allowed for some amazingly detailed and lifelike graphics from what was at the time like a barely capable 640x480 16 megabyte card.

In this way you could use 2x 256 textures (or one 256 texture and one basic math shader) to give *MORE* aparant detail on objects than even a 2048 texture would allow, even when zooming in.

Its actually something that has been under-utilized for years and is just now starting to make its way back into 'vogue' with games like F.E.A.R. etc

Unfortunately with the large number of people using extremely primitive and poorly capable intel chipsets in SL, shaders have basically been pushed back indefinately, and along with them hopes of giving a 'third' option of raising detail (without raising rendering load or texture downloads much)

Nah michi is tryin to show what the 'effective' resolution was between 'source' textures of 2048 (third, giving 1024x1024 per frame), 1024 (second, giving 512x512 per frame) and 512 (first, giving only 256x256 per frame)...

We thought that LL had decided to allow 2048's and decided to give it a try, it was not an absolute requirement it was just something people had asked for for a while (clearer/cleaner lines) and we took the oportunity to see what we could do with them... When it became aparant it was a problem we immediately pulled them and re-issued them witht he more standard 1024 base.

As to client lag tho you will find that 2048 textures actually cause very little (as long as you are using a video card with at least 128 megs) and alpha screen coverage (how much of the scrreen is covered by how many translucent polygons) causes much more. Network issues and cpu drawing of complex shapes also use much much more.. (if you wanna test that in the client debug you can turn off rendering of alpha and see how much your framerate improves)

If you wanna test it, set your video card to a lower effective ram size (choose 64 megs in the sl preferences) and see if your framerate goes up significantly... by in large it does not.. Infact it often will not go up at all... SL is tremenduously cpu bound as long as you are using a 2004-2005 or newer video card, even low end ones... And texture size has just about no effect on cpu since the video card swaps via DMA (direct memory access) and does not hit the cpu at all for textures.

Again not to say that 5000 2048 textures at once is a good thing, it just is not what is currently causing people's slowdowns, and 'capping' them is not going to raise anyone's framerate from where it is now.

Aside from the question if textures beyond 1024x1024 pixels make any sense - the SL website makes a an interesting statement:

Intellectual Property (IP) Ownership
Second Life Subscribers maintain IP rights for the digital content they create and maintain in Second Life, including avatar characters, clothing, building, scripts, textures, objects and designs. You own what you create.

So, what we upload and create is owned by us. One should think it can't be changed, resized or re-compressed without our permission. The creator owns the files, just like images hosted on rented webspace. But yet existing textures get sized down without asking or even a warning? I find that a bit strange. Way I see it, some of my display textured suffered quite a quality loss and I didn't give anyone the permission to change the files that I own.
If someone finds out the maximum number of prims within a link set causes lag and problems, will prim linksets get resized then? Some prims of existing objects deleted, just like texture pixels?

You don't own the files themselves, you own the IP rights to their dstribution within SL, kinda a difference. Think of it like creating a song with the f* word in it an havin the radio stations blank it out when airing. The big texture thing was a bug, and its bein 'censored' for the benefit of keepin SL runnin ok and not kernel dumping specific apple made computers with bad video card drivers

I have some personal experience to relate here. I'm the friend of Barmovic he's talking about.

At Burning Life recently Of Oz and I displayed a huge 100m cylinder of 250prims, with a single texture on the inside surface. We used 360degree panorama images. The best was taken from the top of Everest, about 12000 pixels wide, and we resized it down to 8192x4096, and uploaded it without a hitch for L$10 (how ridiculous not to charge more).

We had calculated that this was the right size to show the visible portion at any time at resolution commensurate with what peoples screens could display.

The effect was astounding. The appearance of being actually on the summit was strangely enhanced by the dual nature of the illusion - virtuality within virtuality. Almost every visitor was blown away by this experience. It was so good that even I gazed at it in awe, exploring the summits below me and tring to decode the geology.

It was so different from looking at the flat picture, which alone seemed to hold none of this interest.

Four days from the end, this issue with Michi having blown up in the forums, I arrive after the update to find the whole everest panorama effectively destroyed. Along with the others, like the Mars panorama from NASA. So blurry as to be useless except as an atmospheric background. Took me ages of digging around to realise what had happened. Textures had shrunk.

So. Here we are. Apparently we unknowingly did something hugely technically irresponsible, and everyones video cards should have been crashing around us.

Did they ?

They did not.

I spent a huge amount of time in attendance, greeting arrivals and explaining it to them. Not one person reported a problem, no crashes, no freezes, no slowing of frame rate.

All that happened was that the panorama took a while to load. It was gray for a bit (aren't we used to that), and then kicked in gradually to higher resolution, as a progressive jpg should.

Some people rezzed it as fast as 10seconds initially, with about 20-30seconds to full resolution. For some the whole process took a minute. They were warned to be patient because it was big. But remember, this one texture was filling almost their whole vision - and how long does any new full-screen-scene take to load ?

It was worth the wait. Once loaded it was rock solid, even if you turned quickly.

No-one was in difficulty seeing it. I only have a 64MB graphics card.

So if you technical guys are right, how was this possible? Admittedly, this single huge image was spread over 250 prims, and maybe you will say that is why it worked. But I don't think so, because the panorama controller was a single prim with the same huge image on, and that caused no trouble either.

While not terribly knowledgeable on this, I have intercepted the OpenGl commands, and find that textures sent to the card appear to be both fragmented and resolution-reduced , and they appear to relate more to what is in view than which prim they are on.

So basically - I don't believe any of this technical doom-talk about big textures being unhandleable by client or graphics card, or increasing lag. I have seen the proof, as have 600 visitors to Burning Life.

I agree that this unilateral reduction in texture size is a in fact a "non-technical" fix, to cut all the inappropriate texture usage. Not to prevent technical problems with big textures.

We are now rescripting to spread 32 1024x1024 textures across the 250 prims, so should be back on track before long. But how ridiculous and unnecessary. The new uploads will cost us L$320 per big panorama. We'd willingly pay 10 times that as a single texture.

We may even find we are forced to upsize the smaller ones to this standard, so that the end result is more bigger images than necessary. Great outcome.

No this was a specific driver bug relating to mac pro's (the tower things) with the stock 7300(gs? i think) and the osX 1.4.7 system video driver...

As i have said multiple times bigger textures should be fine for modern graphics cards, the specific crash problem was a *video driver bug* on a single specific computer type running a specific (now obsolete) revision of the system

I do believe that in all likliehood you were seeing the image 2048x2048 as that is the maximum addressable size most modern video cards can draw textures to... Thogh it is possible that that size does not apply to the memory storage but only the output buffer, so it is possible that by using multiple prims and sub-sectioning the image, it was able to skate around and get full resolution output but thats not something i've ever really looked into doing.

I really don't think so, eltee. I was not in fact cut back by the update to 1024x1024 (as new uploads will be) but to 2048x2048. This was the blurry image which upset me so much.

If you think about what the video card has to do - it must always fill your whole computer screen. In SL you will end up with a whole fixed-size screenful, pulled off literally hundreds of textures on hundreds of prims. More than a screenful because of partial transparency. Presumably the system (if not the card) will also be holding hundreds more partially occluded bits ready for when you shift viewpoint.

We know that in fact the card can shift this stuff around much faster than the CPU can ask it to.

My opinion is that it doesn't matter which prims, or which whole textures of which size, all these myriad picture bits come from. It is the task of OpenGL and the GPU to do all the necessary chopping, cacheing, moving about of all these bits. I suspect that he size of the original uploaded texture is absolutely irrelevant. What you need is a screenful, and that is what you get.

Increasing your visual range will pull more objects into view, with more partial transparencies to compute and more stuff to download, and this is what matters, as we know so well.

In fact, filling your screen with part of one huge texture is perhaps about the kindest thing you can possibly do.

I really think all this talk of big-textures causing problems is simply wrong. A red herring. On this, eltee, we seem to be agreed.

Exactly. Like forbidding cars or greatly reducing their maximum speed instead of introducing traffic rules.

I'm sure there are a lot of other things used irresponsibly. Things became a lot slower when the new lighting system was introduced, for example. I'm sure a dozen light sources in a single room causes more severe problems than a dozen large textures. Or LSL, the root of all evil - people manage to bring down the grid using LSL. Why not remove most of those dangerous commands? At least all of them that could be used in irresponsible and inappropriate ways.

Or the particle system - now, that would be my favourite. Because without all those blings, poofers and whatnot I could finally shout "good job" too. I personally don't use it, so I'd be able to fully support that restriction without thinking of all the crafters who need it and use it in a responsible manner. Must be nice to be on that side of the fence.

The particle system has legitimate uses, banning it out of hand "because I don't use it" is hardly community minded. I dislike poofers and bling and still use the particle system and use it quite a lot for a variety of things. There are amazing works of art produced by it too. But, if you really never use it, just turn your preferences for particles down to 0.

Whilst I agree there are legitimate uses for larger than 1024 X 1024 textures all these things are a balancing act. Limiting texture size is still not stopping you doing things with textures after all.

Sure, it would be lovely to have the right to petition someone to say "but my case is special because..." and have each one judged on its merits. Over time, love it or loathe it, LL has moved away from that situation (despite shouts of FIC to the contrary), to a situation of one automatic rule for all. Each such decision will have people saying "But..."

Against that you have to judge greater good for all. Huge textures used inappropriately are a pain and a major source of sims running slowly when people are trying to download them. Whilst I feel sorry for all of those of you with legitimate uses that are suffering this change, it's one that *overall* I think is a change for the better.

If you can come up with a system that lets someone or some system judge "Yes, this is a legitimate larger texture" I'll support you to the hilt. Until then I'll cry about the loss of Everest, but just like I'll applaud speed limits depsite the fact they can, and do, build cars that travel as 250mph+ limiting speed and the ways we can kill ourselves and each other isn't daft, nor is limiting just how much impact you can have on a sim and the other avies.

Eloise... I think you failed to notice the sarcasm in my post Of course I don't want the particle system removed / changed. I don't want any of the existing features removed or limited, that's exactly my point. Many people wrote in this thread that they like the new texture limitations, things load a little faster someplace, everything's peachy. People who don't happen to need larger texture files. I do happen to need them though, and I think I never used them in unneeded or irresponsible ways.

The particle system, light system and above all LSL scripts can just as well cause lag, client crashes, problems of all sorts. But just limiting it to a point where it can't possibly do any harm limits the functionality and design possiblities as well. LL just has to trust us to use the design tools in a responsible manner. Some will do that, others not, some places will always lag, that's life.

People will still use 1024x1024 textures where 256x256 would perhaps be sufficient. A 1024 pixel brick to create a tiled brick wall texture is madness, when the single bricks are later displayed with a width of 100 pixels only, even when you stand close. Now, should texture sizes be limited to 256x256 to avoid that? Lots of sims are laggy because of hundreds of scripted prims, not poor texturing. The terrorists who lately tried to bring the grid down didn't do it with large textures, they used scripted objects. Should we restrict the number of LSL functions to prevent harm?


There are many possibilities to educate people on texture usage, without limitations that reduce our design options. A few examples:

- Higher upload fees for larger sizes, as Chalky already suggested
- A check of the prim size when applying a texture, with warning messages that the texture is way too large for a small prim and would cause unnecessary lag
- A preview option in the upload dialog; the texture is first displayed at 256x256 (if it isn't already smaller), if you aren't satisfied with the look you click "continue" and preview it at 512x512, then 1024 and so on, of course with the option to preview only the first texture of a bulk upload
- A tutorial that walks new residents through some basic hints, do's and dont's, when using the texture upload for the first time
- An image analysis that checks the contrasts; if there aren't any fine 1 pixel-lines with a high contrast, a dialog comes up asking you if the texture size should be optimized for faster download and display speed

All of that would be better than assuming all users are irresponsible, egoistic or plain dumb and the grid had to be protected of them. But the sledgehammer method of removing or limiting features takes less development time.

I've edited this quite a bit as will be obvious...

Yes, sorry, I missed the sarcasm... I've not seen you post before and it doesn't always translate cleanly through a forum.

Higher fees have been discussed around the place for ages and never implemented. They're easy enough to do... makes me wonder why they've not been implemented. I will assume there is some deep issue about them.

The scaling down option I'd love to see, particularly the last one, suggest an optimum upload size based on the contrast. However... the people that currently upload at 1024 X 1024 or larger for their small prim will add a 1 pixel line to stop it being loaded if they want... especially if they start using particles to annoy on top of every other tool.

I don't think I ever suggested big textures crash the grid... although if the rumours of the luskwood heads crashing some clients are correct that could be a form of griefing I guess. My analogy to speed limits is because actually people will still say "Oh, I'm alright, stuff you mate" and drive too fast. Even if they are fine, they're stressing the system for everyone else, and on average making things worse. People who *ought* to know better, and I'm guilty of it too, still use big textures when smaller ones would do, at least sometimes. I'm certainly not going to go and grab every texture on every item I've bought and resize it to something sensible, although I might just go back over my textures as I reuse them and size them downwards.

We've had 3+ years of unregulated or largely unregulated texture sizes. It's still bad and getting worse. More education *might* help, but despite, or maybe be because of, being a teacher IRL I'll remain sceptical of the take-up and penetration into heads of the texturing data that you're given... it needs to be something at upload time.

But yes. Of course. It's not complex, its not rocket science.
Charge more for bigger textures. Maybe a lot more.
Bingo ! Problem solved.

Griefing, Eloise ?

Not by any stretch of the imagination. The small number of "victims" have graphics cards with a design fault, which manifests with other software than just SL. They are being griefed by Nvidia, not by anyone else.

If all our textures are indeed being capped for their sake, then if anything they are (by proxy) griefing all the rest of us !

Sorry, I was very imprecise with what I said there. I didn't mean to imply you were using it as griefing, I was trying to suggest it could be a way some idiot would try to use it in future. Who'd have thought they'd spam llGiveInventory like they did last week after all.

Actually its not really even causing USER slowdown, by in large the system is good at giving your client only what it needs to draw (32 megabyte cards don't see 1024x1024 textures, they see like 256x256 automatically) its more about server storage and network throughput.

Its not hard to confirm, try a 256 meg card and a 512 meg card in the same computer, and go go the same places in SL, you won't notice any difference at all, i.e. drastically increasing available texture memory on the card provides no real improvement on performance, just visible quality (i.e. a 512 meg card will draw out 1024 textures further before mipping them to a smaller size, compared to say a 128 meca card)

After my inventory textures were shrunk the first time, they were left with the largest dimension set to 2048. Even though new uploads were capped at 1024x1024,

I was hoping we might be allowed to retain at least this echo of our former glory.

But lo ! This update we have the final phase. All inventory textures shrunk to 1024 maximum.

Heaven help the people who spent ages making movies with animated textures.

And I'm going to have to upload my big pictures cut into 32 pieces.

But it is all so unnecessary. 600 people at Burning Life admired my single 8192x4096 image spread across 250 prims, and visibly the one quarter you could see at a time was full screen res. Absolutely no reports of crashing or lag. How can that have been so if even a 2048x2048 texture is genuinely a technical problem ?

Doesn't make any sort of sense except as a one-off reduction of the size of the asset server database. I think that is the actual (unspoken) reason.

So why not lets just choose the obvious, simple, effective alternative solution, and NOT cripple SL as we now have ?

Hi, I came to point this out to you.
The maximum size OpenGL can support on the latest NVidia graphics card is 4096x4096 using a workaround. Most gamer OpenGL compliant cards have a limit of 2048x2048.

SL itself never supported anything higher than 2048.

No offence but it's people who use textures like you do that are "the problem."

There is no need for a 2048 texture on a wall because most people run at 1024x 768 resolution, therefore any flat wall texture that you zoom in on to completely fill your screen (which hardly ever happens anyway) need be no bigger than 1024 x1024.

Also, the texture engine of SL was never intended to show pages of small text, and yes, that *is* what notecards are for. If you want to put a long text description of something out for people, you *should* actually be using notecards.

Even if you chose to do it in textures, there is no reason for the larger size. My vendors all have lots of text on them and they are all 512 x 512. If you absolutely must put that paragraph of text on the wall you could do it the *sane* way and put up a single prim with a 512x512 texture and that paragraph on it and put the rest of th edisplay on seperate prims instead of making people load several textures 16 times the size just so you can be happy about the sharpness of your fonts when you zoom in on your giant monitor at home.

That relies on two false assumptions... Firstly that panels are that size, its not true, 17" lcd's (what the vast majority of computer owners have now) are all fixed at 1280x1024, so that is the average resolution.

Also SL is different than FPS type games where you can never 'get that close' to things, with a free panning camera people can certainly zoom in and fill a whole screen with even just a small portion of a wall, etc...

That said, most of us here are not talking about using big textures for *static* imagery, we're talking about using them for animation, i.e. storing multiple 'image' frames on a single texture and using the client to offet it and play it back like a filmstrip.

i.e. instead of using a single 2048 texture, people are using it to get 4 1024 frames of animation, or 16 512's (or even 64 256's etc)...

That said tho we understand the overall client limitations and as soon as we realized things were causing a problem we rebuilt our content to make use of lower resolution native textures.

One thing i will say is if texture bandwidth within a video system is really that high a priority in SL, one option might be to simply enable texture compression in the client

http://en.wikipedia.org/wiki/S3TC

and do so *OPTIONALLY*, except perhaps on cards with 64 megs or less, where it may be more appropriate to default it to on. That would remove almost all extant complaints about oversized textures 'slowing things down' as suddenly 1024x1024 textures would only take up the rendering overhead of 512's, etc (all modern 3d cards do this in hardware)

This has actually been pointed out to him a couple times. Either he missed it every time, or he is choosing to ignore it. At one point he said something about checking the dimensions within SL and confirming it was the size he was saying, which is either a lie or he simply wasn't remembering correctly.

You are right. He chooses to believe that what is on his monitor is what is actually there. I say anything else at this point is redundant.

I felt like lifting this thread was appropriate in this case. I think everyone who cares about using large textures (and hates misuse of large textures) should vote for the Texture LOD (Level Of Detail) issue in JIRA: https://jira.secondlife.com/browse/VWR-1119

A properly implemented texture LOD framework would help immensely with large texture issues, while still enabling large textures for people who have machines with enough horsepower.

Everything described in that JIRA entry is already in the client and being performed by SL

(capping is happening via your 'video card memory' selection, and progressive download LOD has been in the sl client since god... before i got here in mid 2003 at least)

If this is the case there is definitely room for improvement. Progressive download has nothing to do with the resolution of the textures loaded into the GPU.

If the SL viewer is indeed able to reduce texture resolution if necessary the algorithm probably isn't very effective. Otherwise large textures wouldn't really be an issue if the client could load smaller versions into the GPU if necessary?

Or how can a huge texture for, say, the eyes of an avatar be a problem unless it is indeed loaded into the GPU at full size?

I'm not questioning your claims, but I would like to know the technical details behind them, just being curious.