Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Resizing of Textures Inworld???????

VonGklugelstein Alter
Bedah Profeshinal Tekstur
Join date: 22 Dec 2007
Posts: 808
09-06-2008 04:57
Just an idea mainly - and maybe in the wrong forum but...

Wouldn't it be nice if you could resize textures inworld? How hard would it be to add that feature? It sounds like an easy task for LL. simple buttons in the texture menu to specify 2 or 3 sizes, that way you could pick a resolution...

I know that some people say that 512's are way big enough, but honestly.. compared to a 1024 , the 512's look like hell. But sometimes depending on a size of a build and the application of a texture, it may be preferred to use different resolutions of a texture.


Plus

Paying to upload the same texture in 2 sizes is a drag.
Kitty Barnett
Registered User
Join date: 10 May 2006
Posts: 5,586
09-06-2008 05:25
There wouldn't be any difference between SL resizing a texture and uploading the new size; you'd end up with one new asset just the same as with a texture upload and it would cost you L$10.
Weston Graves
Werebeagle
Join date: 24 Mar 2007
Posts: 2,059
09-06-2008 06:10
Or it could be cool to have plug-ins, similar to VST plug-ins in music workstations. I'm dreaming here, but I agree it would be nice if you could stay in world and have a graphic editor open in a small window and do simple operations on textures. Sure when you "save as" it would be a new name and cost L$10, but you could continue your IM conversations and so forth. I suppose having a program open outside the world amounts to the same thing, but not quite.

Another cool ability would be saving over your old texture to replace it with the new one. That would be very helpful for temporary things like signs -- but the feature would have to be locked out of textures you've already sold. I can see someone at a party in a smashing outfit suddenly wearing pajamas if the designer saves over the wrong texture.

Another nice plug-in would be a simple text editor with spell checker. We're all used to misspelled chat because the chat text editor is very unforgiving. I can't back up and correct very easily without a lot of mouse pointing. I'd like to have something like notepad with a spell checker in a little box for chat rather than the one line thing that scrawls off the edge of the screen if you get the least bit long winded. As I clearly am.
VonGklugelstein Alter
Bedah Profeshinal Tekstur
Join date: 22 Dec 2007
Posts: 808
09-06-2008 06:14
correct me if I am wrong, but the viewer already provides you with several versions of a texture when its loading in steps... so the feature seems to be there, it just cannot be manipulated by the user

we are talking about display resolution, there is no need for a unique asset ID..
Kitty Barnett
Registered User
Join date: 10 May 2006
Posts: 5,586
09-06-2008 07:17
From: VonGklugelstein Alter
we are talking about display resolution, there is no need for a unique asset ID..
So you just want to keep the texture as-is on the server and have a "resolution divider" as a new face property? :confused:

The progressive resolution isn't intented to be pretty, it just shows *something* while the rest of it is downloading. A progressive 256x256 out of a 1024x1024 isn't going to look anywhere near as good as that 1024x1024 downscaled to 256x256 so the viewer would still have to download the entire 1024x1024 and no savings there.

Now assume that that texture is applied to a box: 5 faces have a 1.0 divider (as is) and 1 face has a 0.5 divider (512x512). What would you do? :confused:

The texture UUID for all 6 faces is the same so in order for the viewer to tell the difference between the 1024x1024 texture and the downsize 512x512 it needs to need to generate a temporary local UUID to tell them apart and do note that you just increased the texture size of the texture by 50%.

If another prim has the texture applied with the same 0.5 divider it can't get its own new UUID since that would add another 50% of bloat so the viewer needs to keep a lookup table of resized textures.

Or you can argue that it should only keep the texture as the largest requested size so in the example it would just keep the 1024x1024 in memory and if it only consisted of 0.5 then it would keep 512x512 in memory, and so on.

Now it can't save the 512x512 resized version into the cache because it has the same UUID as the 1024x1024 one and it can't overwrite the original texture so you're either stuck with resizing the texture each time it gets swapped in (which is constantly) or settle for a lookup table with temporary UUIDs which will cause a slowdown.

There is no gain anywhere, just pay the 3 cents it costs to upload a texture.
Nina Stepford
was lied to by LL
Join date: 26 Mar 2007
Posts: 3,373
09-06-2008 08:12
a 1024 texture is four times larger than a 512 and too many of them quckly add up to a laggy sim and a fully cached out video card. its definitely a case of diminishing returns.
i can only think of a handful of scenarios where a full 1024 is anything other than overkill.
From: VonGklugelstein Alter
I know that some people say that 512's are way big enough, but honestly.. compared to a 1024 , the 512's look like hell. But sometimes depending on a size of a build and the application of a texture, it may be preferred to use different resolutions of a texture.
VonGklugelstein Alter
Bedah Profeshinal Tekstur
Join date: 22 Dec 2007
Posts: 808
09-06-2008 08:22
From: Kitty Barnett
So you just want to keep the texture as-is on the server and have a "resolution divider" as a new face property? :confused:

The progressive resolution isn't intented to be pretty, it just shows *something* while the rest of it is downloading. A progressive 256x256 out of a 1024x1024 isn't going to look anywhere near as good as that 1024x1024 downscaled to 256x256 so the viewer would still have to download the entire 1024x1024 and no savings there.

Now assume that that texture is applied to a box: 5 faces have a 1.0 divider (as is) and 1 face has a 0.5 divider (512x512). What would you do? :confused:

The texture UUID for all 6 faces is the same so in order for the viewer to tell the difference between the 1024x1024 texture and the downsize 512x512 it needs to need to generate a temporary local UUID to tell them apart and do note that you just increased the texture size of the texture by 50%.

If another prim has the texture applied with the same 0.5 divider it can't get its own new UUID since that would add another 50% of bloat so the viewer needs to keep a lookup table of resized textures.

Or you can argue that it should only keep the texture as the largest requested size so in the example it would just keep the 1024x1024 in memory and if it only consisted of 0.5 then it would keep 512x512 in memory, and so on.

Now it can't save the 512x512 resized version into the cache because it has the same UUID as the 1024x1024 one and it can't overwrite the original texture so you're either stuck with resizing the texture each time it gets swapped in (which is constantly) or settle for a lookup table with temporary UUIDs which will cause a slowdown.

There is no gain anywhere, just pay the 3 cents it costs to upload a texture.



haha .. now we are talking..

whatever you just said.. I agree .. but it would still be nice if it were set up that way. I have uploaded about 700 textures in the last few months.. the 3 cents are not an issue.. its the amount of time it takes to resize/upload and file them
VonGklugelstein Alter
Bedah Profeshinal Tekstur
Join date: 22 Dec 2007
Posts: 808
09-06-2008 08:40
From: Nina Stepford
a 1024 texture is four times larger than a 512 and too many of them quckly add up to a laggy sim and a fully cached out video card. its definitely a case of diminishing returns.
i can only think of a handful of scenarios where a full 1024 is anything other than overkill.


Overkill can be a good thing under the right circumstance.. my connection speed is fast and unless I am in the store where there are too many huge textures I have no issues with lag from large textures .. most builds do not use hundreds of 1024's like a store selling them. I think that lag is higher from Avatars walking around with 115 attachments than a few large textures.

4 times as big means 4 times more betterer looking on my huge screen...

I hear this argument made a lot, but its all personal preference..same with draw distancees. I am trying to figure out how to offer the option of lower resolution (lower quality) textures to people that do have slower connections or load speed without the need for them to buy several versions of the same texture, hence the this post.. I do make some smaller lower resolution textures for things that can look good at lower resolution, but you can never achieve as crisp or good looking image with a texture that has only 1/4 of the pixels compared to one that has all of them.

:) \m/
Porky Gorky
Temperamentalalistical
Join date: 25 May 2004
Posts: 1,414
09-06-2008 17:41
I always try to build and texture to accomodate the lower spec PC's. My PC and connection are top of the range so i have no probs with a lot of 1024 resolution textures, but i have to accomodate all customers and try my hardest to reduce lag and loading time for customers on lower spec machines, so rarely use a texture above 512 resolution either in my store or in an end product.

As far as texture resizing goes, that would be handy, I would like to see a plugin or something that offered basic edit & rendering tools like crop, brightness, sharpen, blur etc.
_____________________