SL Texture Question

As many of you know, I am a lover of great textures, and when I find them, I try to point everyone to them. My question is potentially stupid...

I have always been of the belief that 512x512 textures are ideal for SL. Is that correct? What about 1024x1024 textures? Are they too big for SL to handle?

Thanks!

1024's aren't too big for SL to handle, but having too many of them in view can severely slow down client performance. Consider that every single one of them consumes 3MB or 4MB of texture memory (4 if there's an alpha channel, 3 if not). Even 512's are pretty big, memory wise, each one using 768KB or 1MB of texture memory.

I always recommend that most textures be 256x256 or smaller. A 256x256 only uses 192KB or 256KB of texture memory, and a 128x128 only uses a quarter that much, 48KB or 64KB.

SL happens to be better at blowing up small textures to full screen size than just about any program I've ever seen. I'd even go so far as to say that's it's best feature. It's really, really good at that. It's easy to see that simply by rezzing a cube and zooming all the way in on it. It looks just as good up close, filling the whole screen, as it does from far away, filling just a small portion of the screen.

If that cube has a 256x256 on it, at full zoom, you're seeing the texture at at least 16 times its actual size, but it still looks pristine. That's impressive.

Anyway, the biggest reason SL runs as slowly as it does is because of texture mismanagement. Most of the textures people use are way bigger than they need to be, and video cards simply choke as a result. When the video card's memory fills up, the leftover textures need to go into system RAM, which is much slower. When system RAM also fills up, anything else leftover goes into hard disk virtual memory, which is glacial.

There is no universal ideal size for all textures. What you always want to do is go as small as you possibly can while preserving the integrity of the texture detail. For a simple design, that could be like 8x8. For a photo of a document with a lot of fine print, it might have to be 1024x1024 for everything to be legible. For most images, 256x256 is a good happy medium.

Also remember that you can tile textures. So for instance, if you are doing a wall with the same repeating texture, but you want nice detail, instead of uploading a 512x512 texture, make it a seamless 32x32, 64x64 or 128x128, etc. and just tile it on. The wall will look the same but take much less time to load.

Except for textures that are very skinny in one direction, you usually need to choose between being able to tile a texture, and Chosen's idea of combining textures into a single texture sheet.

The way you select a partial texture (multiple images in one texture) is by specifying a texture repeat value that is less than 1.0 in the horizontal and/or vertical direction, while using offset values to 'aim' at a specific part of the texture.

The way you choose to tile a texture is by specifying a texture repeat value that is greater than 1.0 in the horizontal and/or vertical direction.

The two are mutially exclusive, unless you have several textures that are narrow in one direction, and which need to tile lengthwise. For example, if I wanted to make a texture that had ten types of edge banding for furniture, I could use a vertical repeat of 0.1, combined with a vertical offset to select the type of banding, but a horizontal repeat greater than 1.0, to repeat around the rim of the table top.

Thank you very much for the good info!!!

I have evidence which suggests that this is simply not true. Presumably because the GPU (Graphics Processor Unit), together with OpenGL, is much smarter than this would imply.

I believe you dont even download a whole texture unless it fills so much of your screen that you need it all. Once you have downloaded it at an appropriate (maybe low) resolution, even then it doesnt all go into the texture memory. Bits are flung in and out at high speed as they are needed, again only at a resolution high enough to satisfy your actual needs.

So download-wise all you get is a screenful plus some for transparency, etc. You always need a screenful, and it can take a while whatever you are looking at. Go to a new area and see.

These are my conjectures - I don't have time to fully brief myself on the technology, nor do I have access to the client code.


But I can report practical evidence that big textures do NOT in practice cause more problems than any other screenful of SL scenery.

I post my rather startling evidence in my next post, just below....

Briefly my evidence is this:

At Burning Life 600 people visited my exhibit. They viewed a single image, 8193x4098 pixels, which (to my surprise) I had uploaded for L$10. Not realising this was not supposed to be done.

They viewed it spread across the inside of a huge 250 prim cylinder.

Surely the sim should have crawled to a halt, clients and cards crashing and freezing, image breaking up, apalling lag etc etc. If everything we have been told is true.

This did not happen. The life of the sim went on around us. 600 people visited. Everyone moved about normally. No-one reported any crashes (I was in attendance lots of the time). All that happened is that the image (about a quarter of which filled our screens) started off grey, and took about as long to rezz as any normal full new scene always does. Kicking in to progressively higher res, just as it should. Ending up visibly full-screen-res (as a quick calc will tell you it should).

Once rezzed, the image was perfect, stable etc. And, incidentally, stunning (Everest) ! I observed absolutely no deterioration in client performance whilst watching it, or walking about with it in the background.

This was a HUGE panoramic image, clearly (in retrospect) almost illegal. I unwittingly did the thing we keep being told is too damaging to allow, and it all worked perfectly.

Can anyone explain this ?

Note that my little graphics card ( and those of many of the 600) is a puny 64MB.

Isn't what I report supposed to be impossible ?

You are talking about a single texture in the optimal situation, having just that one texture in view and nothing else around. The problem is that they add up fast.

But every scene has hundreds of textures in it, in partial view, at varying degrees of "magnification". We have no choice but to download enough of it to fill our monitior screens, one way or another.

I have yet to see any clear technical argument to say that viewing 4 prims each with 512x512 on them is any way more difficult for any part of the system than viewing one prim with a 1024x1024 on it and filling the same part of the scene. Its all just data.

The only difference is in the model inside the graphics card, and that is hugely fast compared with the slow CPU which is sending it instructions.

As a test I put the same huge image on several little prims and looked at them simultaneously with the big one. This gave no problem either. I was observing from a complex multiprim platform, which was partially in view, along with a projectin crane boom to enhance the 3d illusion.

Can you explain this ? If you see the nature of the problem everyone is so sure exists, where in the system is it occurring ? No-one seems to know. They just trust its there somewhere because someone says so.

One moment its the download time, next its the graphics memory, and then the graphics processing. Can anyone be precise ?

Not just someone, Linden Labs. Y'know, the people who made SL? They're not perfect, but could you tone down the ranting for just a sec and consider that maybe, just maybe, they know a thing or two about how the software they wrote works?


That question is irrelevant because it's not an applicable situation. That was my point, that SL involves lots of textures at a time, not just one. Thus, the issue is really "is there a difference between four 512 textures and four 1024 textures?"

I can see other reasons LL might want to reduce texture size. Like the size of the database on the asset server, which we know is in trouble.

This is a perfectly valid reason, but it is nothing to do with crashing or slowing clients.

The world is more subtle than we might think, and even in dealing with things technical, we need to look at motivation if things seem to not quite fit with the superficial explanation.

No-one from LL has told direct untruths, it's just a matter of presentation, and the difficulty of getting to the person who really knows. It's even possible they might be surprised by my evidence. LL did not write all our OpenGL drivers, nor manufacture our graphics cards.

Please note - I am not claiming I am right. I am just making a case and presenting surprising evidence. I am still waiting for any properly thought out counterargument whidh can explain that evidence.

If I'd known what was going to happen, I'd have conducted a more comprehensive experiment, but now its too late.

Be aware, many content providers are suffering difficulty and loss through this decision. Querying it is therefore perfectly reasonable.

You are talking download time, Johan ?

That would then only be true if

1. The client had to download the entire full res texture for every prim in view, no matter how far away. Including a tiny sword hilt 2 or 300m away,right at the edge of your view.
and
2, The three small prims which were replaced by the bigger prim still existed in the field of view.

Surely no-one believes 1.
And the four little prims are gone. The big on has replaced them, carrying alone exactly the texture information they shared. They cannot be seen. The data transferred is the same, and it covers the same bit of the screen. It just comes from one asset, not four. Looks like a saving in housekeeping to me.

I think there are two different issues being confused together here by us, and maybe even by LL.

1. Is it damaging to server or client to use 1 prim with a big texture to replace four smaller prims which look exactly the same ie sharing the texture data between them ?

I am arguing for "no".

2. Is it damaging to server or client if everyone in SL uses textures much larger than they need for their purpose ?

The second answer is of course "yes".

It'll certainly damage the servers by wasting valuble storage and slowing access times and wasting the computations necessary to process the data before sending it at an appropriate resolution for the distance from the viewer. Everyone I think accepts this is damaging, or at very least a waste of resources.

Whether such abuse of the texture data will damage the client is totally dependent on how well the servers perform at not sending more data than needed.

If the server always sends only what is necessary to the viewing range, then the client gets no more than it needs, and has been insulated from the abuse the servers are suffering, with no increase in download time or processing.

If the server does no reduction, but sends the client everything about every prim in range and not occluded, then we have disaster for the client too. The abuse causes huge unnecessary downloads, and similar stress inside the client until it has cut out what is spurious.

Where are we between these two extremes ? In one case all this server abuse doesn't get near the client, in the other it too is in real trouble.

My guess is we are in between these two situations, with the progressive jpgs on the server allowing three or four levels of detail to be selected as appropriate.

Which means that texture abuse does damage the client some, but nowhere near as much as it does the server.

My conclusion :

Appropriate controlled use of big textures in place of many equivalent smaller ones which would otherwise have to be viewed does no harm to anyone.

Inappropriate uploading of unnecessarily big textures (as happened for three years and is still happening) hugely stresses the servers quite needlessly, and stresses the client some, but less because the servers partially protect them from unnecessary detail.

Recommended action:
Allow use of big textures, but charge much more for upload, to prevent use which is inappropriate.

This may be one of my longest posts ever, and I've had some long ones. I couldn't help it. I started responding to all the untruth being spewed around, and I just couldn't stop until I got through all of it.


Absolutely not true. If this were the case, you'd need to re-download every time your point of view changes. That would be ridiculous.


When you download a texture, you download the whole thing. Your conjecture is way off. The server doesn't monitor your point of view and then say, "I think this guy's only gonna look at this texture with just X amount of pixels, so I'll take all the trouble to downsample the image on this end so I can send out a brand new, lower res version." It just doesn't work that way. It sends you the whole texture once, and then that part of its job is done.


Complete fantasy. The server has no idea what a "screenfull" is. It simply sends you the textures that your client asks it to send you. It doesn't change them, doesn't re-sample them, doesn't fracture them, doesn't substitute them for naked pictures of your mom. All it does is deliver the specific files it's asked for.


Now you're using the right word, "conjecture". That's all it is.



I wouldn't exactly call it "evidence", but let's talk about it.



It can be explained quite easily, actually. You're forgetting one very important fact. SL has a cap of 1024x1024. It was upped 2048x2048 for a while, but that's as high as it ever went. It's now 1024x1024 again.

When you uploaded your gigantic texture, your SL client resized it to either 1024x1024 or 2048x2048, depending on when you did it. In either case, it's 1024 now, as LL downsized all existing large textures to 1024 a couple weeks ago. Throw that texture on a prim, call up the texture console, and you'll see.

Even if the resizing hadn't happened though, it's not like one image at 8192x4098 would break most systems. You're talking about 96 or 128 megabytes of texture memory, depending on whether it's got an alpha channel or not. That's not enough to make an average computer choke.

The average scene in SL has gigabytes worth of textures on display, and all of our computers still run it. They just run it much more slowly than they would if the textures were properly optimized, like they are in video games.


Uploading an 8192x4096 is impossible, yes. Viewing one is not.



What you download is whatever your client asks the server for, file by file. The client does not have the luxury of saying, frame by frame, "Okay, Server, old buddy, give me 3/4 of this texture, 2/5 of that one, and half of this one over here. I'll be back at you in the next fifteenth of a second to tell you how I want you to slice and dice the images next." Again, it simply doesn't work that way.

It's not about "filling the screen". It's about acquiring all the assets to fill the scene. There's a huge difference there.


Here are the parts of the system it's more difficult for:

1. The sim - It has to make 4 calls to the asset server to request the four individual files instead of just one, every time someone comes into viewing range, and then it has to send those four files to each client instead of just sending one.
   
   
   
2. The asset server - It has to answer the four calls, and send the four files, instead of just answering and sending once.
   
   
   
3. The SL server network as a whole - All those extra asset requests mean a huge amount of unnecessary network traffic.
   
   
   
4. Your ISP - Four files need to be sent to you instead of just one. Sure, the total size in bytes is the same, but the amount of individual files is quadrupled. The internet has to do roughly the same process has the SL servers in order to deliver all four. That's a lot of unnecessary network chatter.

What it's not more difficult for is anything actually having to do with graphics. No one here said that it was. All your graphics card cares about is how many pixels it has to keep track of. It couldn't care less whether those pixels are in one big file or a million little ones.


If by "model", you mean the 3D geometry, that's actually the smallest part of the whole thing, and it's really not a variable anyway. Whether you view one texture across 4 prims or 4 individual textures, the 3D geometry is exactly the same. It's the number of individual texture files that is changing, and that has nothing to do with the geometry.

If you meant something else by "model", please explain.


Your test doesn't seem to illustrate what you've been talking about. You put the same image on lots of prims, right? That's not the same thing as trying to receive lots of individual files. You've already got the one image cached. There's no downloading involved at that point.


Precise about what, exactly? I'm not sure what this paragraph is supposed to mean.

Download time is directly affected by the number of files, and the size of each one, as well as by many other chaotic factors beyond our control.

Texture memory is calculated as a function of the total number of pixels in all the images stored in your graphics card for viewing. Whether you've got four 512x512's or one 1024x1024, the amount of texture memory is the same. However, since the 512's constitute four times the amount of files, it's harder on the network to deliver them to you. Once you've got them though, your own graphics performance will be identical between the four or the one.

Is that what you were trying to ask?


Newsflash: If you upload four quarter-sized textures, it's the same amount of file space as one big whole-sized one.

The reason LL has capped the texture size at 1024x1024 is because not all systems can handle textures larger than that for real time applications, and because it's good common sense. Take a look at the textures in video games some time. 256x256 is generally considered large for a game texture.


Valid in theory, maybe, but it's not the actual reason. Crashing clients were the why LL removed our ability to use 2048's. Obviously, anything bigger than that would cause the same problems. There's never ever a reason to go that big for real time applications. There's rarely even a legitimate reason to go as large as 1024x1024.


Well said. I invite you to look at your own posts in this thread in that very light. You're making all kinds of unfounded assumptions in some sort of attempt to talk the rest of us out of our prior understanding of the facts. I'm not sure what the motivation behind that might be. Are you?


First, your "evidence" does not exist.

Second, you don't have to have written OpenGL to know how it works, nor do you have to work on the floor at a graphics card manufacturing plant to know the architecture involved. For you to suggest LL's highly experienced programmers don't understand technical basics just because they're a mystery to you, yourself, is pretty laughable, you must realize.


Again, it's not evidence. You think you viewed a big texture in SL, and you think you did it without slowing your computer down, and from there, you're making the leap to assume none of the established facts about how texturing works can be true. That's pretty out there.


How's it too late. Experiment all you like. I'd suggest you start to incorporate proper measuring tools though. The texture console goes a long way towards explaining what you think you see.


What decision? How am I suffering as a content creator?



Uh, actually everyone believes number 1, because that is precisely what happens. You do download the textures for every prim in your field of view. However, if two prims share the same texture, you don't download it twice. You acquire the one texture file, and then that file gets referenced by each of the prims to which it is applied. It's pretty simple.

I'm not sure what number 2 means. Three prims replaced by a bigger prim, what three prims? Where? I think you neglected to explain something.

Are you perhaps referring to that experiment of yours where you put a texture on a few little prims, and then on a big prim? If so, let me say once again that that experiment demonstrated absolutely nothing. You're talking about one texture, and one texture only. The amount of prims to which it's applied is not relevant. You could put it on one prim or a thousand prims, and it's still just one texture.




Now that all that is out of the way, let me teach you how to calculate texture memory since the statement of mine you originally took issue with had to do with the memory requirements of variously sized textures. The formula is very, very simple:



So, to put that all together, let's say you've got a 1024x124 sized 24-bit texture. Here's the exact math:



That's how the math works. It is fact, and it is irrefutable. Your "evidence that this is simply not the case" is completely imaginary.



As for your last post, Chalky, the multi-colored one with your summary points, sorry, but it appeared while I was writing this, and now I'm a little too tired to start again. Everything it said was just a rehash of what I already refuted above, so I don't really see the need to get into it.

Okay, I'm glad you pointed this out. I knew this, but somehow reading Chalky's ponderous posts in the other thread almost had me doubting my own sanity, and so I started to wonder if maybe SL somehow only delivers textures at the resolution you need.

Hmmmm... How to answer ?

I think that clarity demands my two questions are kept separate, because they are different.

"1. Is it damaging to server or client to use 1 prim with a big texture to replace four smaller prims which look exactly the same ie sharing the texture data between them ? "

Unless I misunderstand you, Chosen, I think you just answered "no".
Indeed, you go further and argue persuasively that one big one is better for the server, and no different for the client.

This is EXACTLY my own point of view, and it seems we are in agreement. I am puzzled you couch it in terms of a disagreement. You spend half your post lecturing me on my error in having a view totally opposite to what I believe, as stated in bold in the third sentence of my post. Odd. Do you thrive on conflict ?

The answer to Qn1 being agreed, we are probably also agreed that the true reason for LL's action is to reduce inappropriate use of textures, not to stop the occasional fully appropriate big one from damaging the system, because it no such damage exists.

You do say "Crashing clients were the why LL removed our ability to use 2048's.". But I followed that saga too, and from what I saw the only crashing clients were one model of Intel/Mac with one model of Nvidia graphics card. Crashing because of a bug in the card. You surely can't advocate crippling SL further for the sake of these few, who will need to get their cards replaced, as other software is crashing too. And they have found a workaround which is fairly effective ?

All your post except that based on the big misunderstanding(ie that we disagree over question 1 when in fact we don't) is addressed to question 2:

"2. Is it damaging to server or client if everyone in SL uses textures much larger than they need for their purpose ?"

Once again, you say "yes" and so do I.

You take me to task on a matter of degree, because I opine that the downloads must be using a "level of detail" type algorithm to avoid unnecessary texture data going to the client, thus partly protecting the client from the assumed inappropriate textures.

You state most emphatically that the full texture is passed to the client.

"When you download a texture, you download the whole thing. Your conjecture is way off. The server doesn't monitor your point of view and then say, "I think this guy's only gonna look at this texture with just X amount of pixels, so I'll take all the trouble to downsample the image on this end so I can send out a brand new, lower res version." It just doesn't work that way. It sends you the whole texture once, and then that part of its job is done."

If it really is so all or nothing, this must apply even to an almost invisible prim right on the edge of your visual range. If this is true, every texture for every visible prim, in full, whoever designed the system is bonkers.

Look at this .

"Level of detail (LOD) is a term used in game development which refers to a method where an object will change in mesh detail based on its distance from the camera. In Second Life, virtually everything uses LOD techniques, including things like objects, avatars, textures, trees, and even land. The preferences have various settings (mostly under "Graphics Details" to change LOD limits"

Thats the term, "Level of Detail". It is a huge topic for the graphics community - how not to process what you don't need to see.

There is no doubt SL relies hugely on sophisticated LOD techniques.

BUT, you will say - that is all in the client, because only it knows exactly where you are looking.

You will claim presumably that the client always gets the geometry in full detail too, even for an object on the edge of its visual range, which may only paint 4 pixels ? I would be astonished at such abuse of the thin data pipe from server to client.

Obviously, we should do eveything we can to do at least some of the LOD data reduction at the server end.

We are not prevented even if its true that the client alone knows what it needs, because the client can pull. Or, even simpler, if the data comes as increasing detail, the client can simply say "stop" when it has enough.

So does SL do this somehow, or are you right that all of every texture is always transferred ?

You are wrong. Of course you are wrong. How do I know? Because I know that the server sends progressive jpegs. I have seen them click up the resolution in stages.

Even if it does nothing cleverer, the system stops transferring more detail at some point where the client definitely has enough.

This is why texture sizes go up in powers of two. The server can provide a range of sizes, each twice the one before, and the client gets the one it needs.

I am astonished, chosen, that you have gotten so aggressive, and so judgemental, and so dogmatic in your reply, and largely on the basis of having mistakenly reversed the meaning in my first three sentences, and then forgotten the existence of the huge literature on LOD, and the evidence of our own eyes that there is at least a minimum "pull" implemention of LOD (actually DLOD), using progressive jpeg.

As for your dismissal of my big texture experience with:

"When you uploaded your gigantic texture, your SL client resized it to either 1024x1024 or 2048x2048, depending on when you did it."

Where did you get this idea that I am a bit of a simpleton ? I tried the upload to see what would happen, to see how hires I could get my big panorama to be, and was astonished when it displayed on a prim at this superb resolution. You think I didnt check ? Put a photoshop window of part of the huge original right next to the same bit on an SL prim ? Of course I did. Maybe there was a temporary bug which let these textures through, but through they most emphatically did get, and were also declared as this size in the texture inventory window.

Yes, of course I know these textures are now 1024x1024. I already posted about that in another thread (sigh). Are you unaware how condescending you are being ?

Please, Chosen, show a little more respect for others. I don't know you, but there really is no need to be so rude and insulting in your tone. And, as it happens, quite substantially wrong in both assumptions and statements of fact.

My only real interest here is that I am trying to get the situation crystal clear in my head so that I can have one more go at persuading LL to solve this by enforcing responsible texture use, rather than by crippling it.

Faint hope. It seems almost no-one is willing to separate Question 1 from Question 2, which separation I now see to be the crux of the matter.

Your very last sentence sums it up: if this astonishes you, then be astonished. Amusingly, you even anticipate the correct response, but for some reason refuse to believe it. LOD is a client-side operation. The server still sends all the data, and then the client performs LOD to speed up rendering.

The last bit btw is getting at a 3D graphics term: culling. Occlusion culling is a very expensive operation, that requires long preprocessing of the data for a videogame to do it. Without a BSP tree or something similar then yes, polygons are always drawn when in the view, even if only part is visible. It is more expensive to determine which little bit is visible so that you only draw that than it is to simply throw the entire thing down the pipe. Notice how you can see the inside of buildings before the walls have rezzed? Gee, why should the client download the interior if you cannot see it because it's on the other side of a wall? It's because the amount you would save in sorting that out is far outweighed by the cost of figuring it out.

And the funny thing is, I'm just talking about the speed of this data shuttling around within your computer. The communication between client and server is of course way slower, so if it takes too long to do this stuff within your computer, then it would definitely take too long to do this stuff in communication between the client and server.

ADDITION: Hm, in rereading this, I notice it is mostly about polygons, which is a tangent. Long story short, LOD is a client side operation, and that includes textures.

No, I don't thrive on conflict, but when I see erroneous information, I do feel obligated to correct it. There are also times when I'm wrong, and other people correct me. That's fine.

We were never in disagreement about your point number one there. I never claimed we were. You never mentioned that point, however, until after I began my reply to all your other stuff, in that multi-colored post to which I did not reply. My reasons were mentioned at the time.

The other stuff you said though was way off the mark, which is why I found argument with it.


Sure. That was never in question. You did try to claim though in your first post here that excessive amounts of large textures wouldn't slow the client down. You quoted my comment that it would, and then you said my facts and figures on the subject were "simply not the case" based on completely erroneous anecdotal evidence that really had nothing to do with anything. That's what I took issue with, and it's got nothing to do with either of the above points.


I don't own one of those machines, and I have no idea whether other software is triggering crashes or not. The justification for using 2048's at all though is so microscopically thin, I see no reason not to remove them anyway, crashes or no crashes. In any case, it's not for me to decide. Clearly LL felt the drawbacks outweighed the benefits, and in their judgment (based on far more information than we have), the crashes were frequent enough and severe enough to warrant this response.

Again, for most real time applications, 256's are considered big. 2048's are unheard of.


No, as I said, you didn't even broach number one until well after the discussion began. Your initial posts were about texture size as it relates to memory and performance, and about how textures get sent from the server to the client. None of that has to do with this "one large texture vs. 4 small ones" subject, at least not in any way that you've outlined.


Okay. Again, that was never a subject of debate.


No, I'm taking you to task on the kind, not the degree. You keep insisting that all these millions of partial texture downloads must be happening from frame to frame. That's just not how it works.

It's not the server's job to know or care anything about how the world looks to you. Your client does that. The server's job is simply to deliver the files the server requests. That's it.


Yes, because it is. It could not be otherwise.


You're confusing file downloads with pixel rendering. They are two completely different and separate things.

The LOD you're talking about has to do with the manner in which the client renders the scene. The way it works is first the client downloads all the assets (in whole), and then it determines how to draw them. If your point of view is far away from an object, it will draw it with less detail. If you're closer, it will draw more. That on-the-fly drawing has nothing whatsoever to do with downloads. Downloading is a one-time thing (per visible asset) that happens well before any of the drawing begins.


It's not abuse of the pipeline. It's perfectly normal, and expected.

What would be abusive would be for the client to constantly have to tell the server exactly what pixels are visible to you. That would be an ungodly amount of data to keep transferring back and forth with every frame.

Really, the server doesn't even know what pixels are. It's not a graphic machine. It just delivers files.


Why? It's not the server's job to render. It only does backend functions like deliver files, calculate physics, etc. Rendering is a client side function.


You seem to be grossly misunderstanding how texture files work. You can't just pull a few bytes out of the whole, and then say "look, I've got 1/4 of a texture now". When a texture is down-sampled, the computer first has to read the entire image, take a look at the actual pixels, and then apply an algorithm to remove pixels and blend the colors of the remaining ones to simulate the presence of the ones that are gone. That takes processor power. Were the server to be doing that for every single texture viewable by every single avatar for every single frame, there would be absolutely no way it could keep up. That would be ridiculous.



Every texture is always transferred.


First, it's JPEG2000, not JPEG, not that it really matters for this discussion. Second progressive JPEG's are only progressive because there's an extra piece of data encoded into the file, defining the progression, allowing you to see the lines of pixels as you receive them. It's not the server applying its own magical LOD mojo; it's just the file, doing exactly what it was designed to do. The speed of the progression is dependent on the speed at which you receive the file.


It stops transferring when you've received the entire file.


Textures are in powers of two because OpenGL requires them to be that way. Any server is capable of storing any file that can fit on its hard drive. The server is only concerned with bytes, not pixels.


Aggressive, maybe, but judgmental, not at all. My only concern is for the truth. I care not who said what. If I know it's wrong, I'll correct it. If something I've said turns out to be wrong, and someone can educate me, great; I'll admit my mistake and thank the person for setting me straight. I can promise you you're not right about this issue though.


One question, and one question only. Did you verify the size with the texture console at the time? No? Didn't think so. Simply holding Photoshop up next to it and squinting real hard doesn't count.

As I've often pointed out, SL is better at blowing up small textures (or small sections of textures) to full screen size than just about any other program I've ever seen. I have no doubt that the texture you're talking about looked spectacular. I also have no doubt that it was either 2048x2048 or 1024x1024. At no time has SL allowed anything larger.


No condescension meant. Believe me, if I were trying to insult you, you'd know it.


Look, I'm sorry if being pointed out as wrong is so painful to you. Outlining why and how you're incorrect though is a far cry from disrespecting you. If you can't tell the difference, then I'm sorry for you. I'd suggest growing a thicker skin.

As for my "tone", we're on a text-only medium right now. Has it occurred to you that whatever "tone" you think you might be reading is merely your own interpretation? The tone in my head when I wrote everything here was perfectly neutral, I can assure you. Again, had I wanted to insult you, there'd be no question that I had, and you'd be feeling it for sure.

As for my being "wrong", if after all this, you still think I am, well then I'm sorry to hear that hanging on to your own assumptions at all costs is more important to you than actually learning how things work. You may notice that there are many forums on this board to which I never post. That's because I don't have much intelligent to say on the topics that those forums cover. I do happen to know a thing or two about graphics though, which is why I post here. Most people are grateful for the information. I'm sorry you're not.


If you really want to get it crystal clear in your head, as with any subject, try listening instead of talking, learning instead of assuming.

Conclusion

Chosen

i) is correct (this time), and almost every one word of it

ii) always enjoys being condescending, although this will never be admitted, but its okay. Its the price someone less knowledgeable pays for gaining knowledge from another. Like those kung fu movies you know. You have to carry large buckets of water on your shoulders and crouch over some burning joss sticks thats about to burn your ass.

Chalky White

i) is wrong. And will continue to be wrong simply due to the lack of clear understanding of how SL, 3D graphics work and networks work

ii) will only start learning when he/she says 'uhm yeah, that sounds more plausible than my fiction old wives tale facts'

Cottonteil

i) likes to bug Chosen everytime she thinks Chosen has made a mistake. This seems to have made Chosen at least a little more careful with words and facts. A point to keep in mind for the semi-knowledgeables when replying.

ii) likes to say 'you are wrong'. (Chalky, you are wrong)

ii) thinks Chosen needs to get more sunlight and fresh air.

(Afterword) I often find Cottonteil's posts irritating and aggresive. I rarely find Chosen's condescending, but always find them informative. I guess tone is in the eye of the reader.

This post however, is my favourite of the day - maybe Cottonteil could use humour and allusion and allegory more often?

I'm sorry, Chosen and Cottontail, but I am bored with this. You are both absolutely wrong.

Go away and learn before pontificating and condescending to others.

Please research the jpeg2000 specification and learn how it allows you to pull an image at a reduced resolution.

As you transfer the file, first you get the data for a small one, eg 16x16. Then comes the extra data to give you a 32x32, and so on till you have it all. Sophisticated highly compressed heirarchical data structure. You can stop at any point, satisfied with the size you have. Or maybe you ask the server for the size you want and it doesnt even try to send the rest, though this complication is not necessary.

SL is surely doing this. Presumably why they chose jpeg2000.

If they are NOT using this ability they are imbeciles.

As for the rest of your post, Chosen, look up "straw man" on wikipedia. Most of what you imagine I said, I never did. Very tiresome.

I'm now leaving this discussion.

Go Google jpeg2000, and see how it allows you to get just a tiny texture for a faraway thing.

Exactly what you deride me for saying SL are doing

From what I deduce of personalities, I don't expect an apology, but I think one is certainly due.

It may be your favorite, Eloise, but if YOU Google jpeg2000, you'll find that even favorites can be totally in error.

Which must surely reduce one's level of admiration, no ?

Anyone else find this hilarious?

Please people, can we all just avoid the word "wrong"? It's pretty clear there's a lot of confusion here, so let's not start stonewalling with absolutist terms.

For my part, I am siding with Chosen on this one. As I already mentioned, Chalky had me half-convinced through sheer force of emotion that I was smoking crack, but Chosen confirmed what I already knew, that the entire file is sent from the server and any LOD is a client-side thing. I will have to look into this progressive jpegs thing because I know little about that, and nothing about how it applies to 3D graphics, but from what I do know about 3D graphics (and I'd like to think I know a fair amount; I did write that previewer, after all) textures must always be complete files for the graphics card to handle them.

ADDITION: And see, your simple exhortation to google it doesn't provide a clear answer. Doing a little digging, while I haven't found anything that says what happens when jpeg2000 is used as a texture for realtime 3D graphics, I did find this page that indicates Chalky may be correct about the progressive download:
http://www.jpeg.org/apps/internet.html

In particular, note this paragraph:
Images saved in JPEG 2000 format can be coded so that the data when transmitted and imaged gradually increases in resolution, starting with a thumbnail, or gradually increases in quality. A combination of these (and other) quality measures can also be achieved - and the user can stop the image transmission once they have enough detail to make their next choice, as the data is ordered in the file in the correct way to simplify its delivery by image servers.

And in particular there, note the part about being able to stop the download at any time.

It's the essence of the argument, Johan.

Exactly why Chosen is indeed actually "wrong" in what he claims.

The client simply DOESN'T have to download the complete full-resolution texture for a far away prim. jpeg2000 allows it not to. Simple as that. What is wrong with using the word "wrong" for such a total and adamant misstatement of the facts ?

Because it is so adamant. Because we haven't established clarity on this issue. You accuse Chosen of being condescending, and he is a little, but so are you. The word "wrong" is, by its very nature, condescending. Although you can still be condescending without using that word, its use is a pretty clear signal that you are being condscending.


It is most certainly not that simple. Googling "jpeg2000" does not return any information about how SL handles these files. Yes, there is some information suggesting that you may be correct, but nothing that states it outright. Perhaps you are correct, perhaps you are incorrect, we're just not sure.


What a great way to get people to agree with you.


Oh yeah, and besides being condescending, you're rather childish. Between your arrogance and Chosen's arrogance, this thread is well on its way to becoming a flamewar.

On an unrelated note, not long ago I wrote a game about flamewars!