[sldev] Reformatting Textures for the cache

[Klaus F. Abel]

Morse Dillon wrote:
> John Hurliman wrote:
>> I've been saying for a while that SL should do away with 1024 
>> textures as well and make 512x512 the upper limit unless they plan on 
>> upping the minimum system requirements. Just a couple 1024x1024 
>> textures will have a 64MB graphics card switching to AGP texturing 
>> (using system memory to store textures), clog the AGP bus and drop 
>> you from 7fps to less than 1. If you want to provide high quality 
>> photo portraits to people, give them a web link. If you want to 
>> texture 3D objects in a real-time online world, keep your minimum 
>> system specs in mind. I haven't looked at that part of the rendering 
>> pipeline yet but in the best case scenario SL is taking your video 
>> memory size in to account and possibly downscaling the images.
>
> I disagree with this on a very fundamental level.  Artificial limits 
> like this are what dates software, and it would be a mistake to do so 
> with an application like SL that has a bright future ahead of it.  
> 512x512 is not sufficient for quality texture work, and furthermore 
> the number of people running 64MB graphics is fewer and fewer each 
> day.  I would rather see SL moving toward taking full advantage of 
> 512MB+ video memory rather than handcuffing it to the past.  If it 
> takes an increase in the minimum specs, so be it.
>
> -M

Hmm, is there anything that would speak against a variable approach...? 
Say, for a system that is low on graphics memory, the client could be 
set to automatically scale down the larger textures right upon download. 
Scaling just by 1/2 or 1/4 shouldn't cost much computing power. These 
systems usually can't run SL at a high screen resolution anyway and 
would probably set it to 800 x 600 to get any acceptable frame rate at 
all - my current rig falls into that category. This feature could even 
be made switchable under the Preferences/Adv. Detail tab.