Charge uploads proportionally to texture size

This would encourage people to think twice before uploading 1024x1024 crap... and would cut down on lag. I suggest that it be a function of the number of pixels, so that people realize that a 512x512 texture is four times less "expensive", and not two, as it is generally thought by the mathematically challenged masses.

How about to the size of the file instead?

A 500K file that is 500x500 pixels should probably cost more than a 32k file which is 1000x1000 pixels.

However I'm glad we see the advantage of constraining people's ability to cause lag

This brings up a point of curiosity for me. What is the highest resolution SL servers actually store? I'm sure if I upload a 4096 x 4096 graphic it is converted to something smaller on their servers.

Remember, that SL converts all uploaded data to JPEG 2000 format. I think all SL textures are at the same quality level as well, so the only thing that will affect the final result (the image that is downloaded when the texture is streamed) is the height/width of the original uploaded picture. Just because the 512x512 texture was bigger then the 1024x1024 texture before conversion doesnt mean it will be bigger after. I may be wrong though, since in the conversion, SL accounts for a TGA file's bit depth and the resultant texture is larger/smaller dependant on the TGA's bit depth at upload.

All in all, this measure wouldn't be to conserve upload bandwith, but to conserve the bandwith the resultant texture consumes when it is downloaded. So, if the resultant JPEG2000 texture file is larger, the uploader should be charged more and vice versa.
==Chris

I think 1024 x 1024 is max but I am not certain. I'm hoping to learn the answer to this myself. When I do texturescans (Alt-3 I think with Debug menu on), seems like that would be the biggest texture size.

I'm not sure if bigger textures should be charged more. However, I am sure that more knowledge of how to reduce lag should definitely be spread around so that few will knowingly use YUGE textures and slow themselves and others down in the progress.

There is legitimate use of 1024 x 1024 textures on giant billboards. *grins*

My question: How are textures scaled relative to different viewer resolutions? Are the pixels scaled relative to each user's individual res., or are the pixels mapped in some way to the world-space (like 1 pixel per every nanometer².)

My guess is that a texture larger than 1024x1024 would be wasted bandwith for people who play the game at 1024x768 or lower resolutions. Because they're only going to see 1024 pixels across anyway, and that's if they zoom fullscreen. Therefore, 512x512 should be fine for most textures that would rarely fill more than a quarter of the viewer's screen, and 1024x1024 is better for textures with small text or other details inended to be zoomed full.

After I posted, I realized the flaw in my logic... of course a texture with a resolution higher than 1024x1024 will look better at a viewer's 1024x768 resolution when that viewer is zoomed to a fraction of the entire texture.... or if only a fraction of the texture is used on the prim.

A good idea in all senses,
but sadly for people to make big textures so they only have to use 1 texture for an intire object. eg, Im a tight git and I tend to put all the textures im going to use for somthing on one big one so I only have to upload one and people only have to down load one.

I tried this once on my first vehicle. I think I used a non-square texture at 1024 across. But, it seemed my vehicle spent more time with blurred textures than looking sharp. So, I reverted to spending the Lindens. I figure if I use 10 textures per object, and sell at least one copy at L$100, I've built myself a free object.

Don't forget to add a multiplier for the 'fugly' factor.

we do need some plain old texture classes that show how one texture can have a hundred uses with variations of spread, shift and colour. i know i know do it yourself. well just maybe i will so there ha!

while we're on the subject, they should charge us something for the amount of storage our inventories are using as well. it doesn't have to be some huge, prohibitive fee that acts as a deterent. i'm just talking about a small weekly reminder. i do tend to trust people's good nature. but it would give us an idea if we're contributing to our own demise.

ll can publish, we're ideally equipped to handle an average of <amount of space> per av. yes yes i trust their good nature as well but won't fault them for undercutting that figure a bit.

remember when we used to be charged play money for processing on mainframes?

I learned myself that playing with the debug, I believe sl resizes all textures to the powers of 2 (^2)...Directx and opengl both require this. So, im guessing the servers, when uploaded, saves it one of those sizes. I dunno...

hehe back when I was a noob I uploaded my first texture, it was a full skin, it was like Feb 5th or 7th or something, way way back before skins got popular...

I think it was 3 textures that were 1600x1600 ROFLMAO stupid noob =P

needless to say Ive gotten my texture sizes all to 512x512 or smaller these days... very rarely do I do a 1024x1024, maybe for instructional materials etc like workspace screenshots etc....

I endorse this idea, maybe other people will start creating 256x256 or 128x128's for their boxes in their shops....

what about pricing? Id go with:

256x256 = 65536 = $L 10.
(65536 / 10 = 6553.6(pixels per $L))

so a 128X64 texture would cost 1.25 $L, but always round up, so $L 2.
512x512 would cost $L 40.
1024X1024 would cost $L 160.

Or could even make it non linear, so 1024x1024 costs even more?
maybe set a minimum cost to $L 5 to offset resource use server side.

Kahmon - the problem with Lindens charging for inventory is that they presently do not give us any good way of sorting and cleaning it. If I could do that on my client then I'd support a charge for inventories larger than X.

good point rose. overage charges would be easier to swallow if you had some good way of cleaning them. various sorting methods and texture previews would be a good start.

That's a great idea. Texture size kills performance for me (I dun have AGP, but I guess it lags people with AGP too when there are dozen of 1024x1024 textures around them) that kind of pricing would make people be more efficient with textures.

Or even, since they already have a method for resizing textures to the nearest power of two, put a resizing throttle on textures. Make 1024 the max. Perhaps throttle particle textures to 128.

now why are you encouraging higher charge prices??? =x

1024x1024 is the max for all textures uploaded in the past six months or so.