texture resolution problems

The texture resolution seems to be very low-res most of the time. Even if i stay in an area forever, it never goes up to high res textures on everything. This is very annoying, as I can't get a correct look at posters and articles on walls etc.

I can hover my mouse / click something and get it to go high res, but it goes back to low res very soon after that.

System is Debian Sid / GeForce 6800 AGP

Known issue, easily fixed
/263/05/85822/1.html

doesn't fix it for me. changing this in settings.ini doesn't make any difference at all

Same here, it changes the greyed-out setting, but doesn't actually make any discernable difference. Client continues to use somewhere around 12-19MB.

Yeah, I used the fix above and the console messages suggest that it's using 128MB, but the game acts like it only had 16MB available regardless. I'm guessing there's a reason it's disabled in the UI ATM.

It made a big difference for me -- I wonder what the difference between your setup and mine is.

I'm using the 256Mb setting:
AMD K7 1.4Ghz
Geforce 2 MX w/ 32MB AGP
1 Gb mem
Debian Stable (w/ some minor backports packages installed)

What are you running?

FreeBSD 6.0-STABLE running the linuxulator for SUSE 9.3.

Strangely, there are various parts of the display that recognise the change, but thus far the client has refused to allocate more than 13mb of textures at once (at least according to the texture debugger).

2006-02-12T15:44:31Z WARNING: Frame buffer has less than 8 bits of alpha. Avata
r texture compositing will fail.
2006-02-12T15:44:31Z INFO: Couldn't initialize mipmap generation
2006-02-12T15:44:31Z INFO: Couldn't initialize GL_EXT_paletted_texture
2006-02-12T15:44:31Z INFO: Couldn't initialize GL_NV_vertex_array_range
2006-02-12T15:44:31Z INFO: Couldn't initialize GL_NV_fence
2006-02-12T15:44:31Z INFO: Couldn't initialize separate specular color
2006-02-12T15:44:31Z INFO: Couldn't initialize anisotropic filtering
2006-02-12T15:44:31Z WARNING: Unknown feature mask NVIDIA
2006-02-12T15:44:31Z INFO: Unable to open image filemissing_asset.tga
2006-02-12T15:44:31Z INFO: Unable to open image fileimg_smoke_poof.tga
2006-02-12T15:44:31Z INFO: Unable to open image fileimg_shot.tga
2006-02-12T15:44:31Z INFO: Graphics Card memory set to 128 MB
...
2006-02-12T15:44:31Z INFO: GL_VENDOR NVIDIA Corporation
2006-02-12T15:44:31Z GL_RENDERER GeForce FX 5900/AGP/SSE/3DNOW!
2006-02-12T15:44:31Z GL_VERSION 1.2 (2.0.1 NVIDIA 81.7

Athlon XP 1700+
768MB RAM

Open up the texture console in "debug". Then compare that with what winows says, in the same area.

I got a value of "-128" (note the minus) as total GL memory, under windows this said 232 MB. Understandably, the cache Logic in SL would then be different, I think.

If you right click an object that will not resolve, and wait a few seconds, it seems to help a lot with loading textures. Even not waiting, and right clicking wildly around, seems to work for me.

Hovering your mouse over Avs works there, somewhat.

For Linden Trees and Land Textures, I have no solution yet...

--- edit addendum ---

And my cache also seems to empty quickly, faster than under windows. The data is not lost though; doing the same right click / mouse hover trick again, loads the texture much more quickly.

And I MUST try that trick of "lying" about my Graphics Ram in the settings.ini. I will set it to max tonight, when I get in world again, instead of the actual 128 MB.

I am curious to see what the texture console says about my "GL Tot" after that... "-512"?



---- edit #2 ----

Setting my graphic card to "512 MB" (5) affects the value BOUND in the texture window, it is now 50/500, instead of 50/116. It does not affect the "-128" GL Tot.

The Discard Bias is high, it was 35 and steadily climbing when I stopped looking - I wonder what it is in windows?

--- edit #3 ----

Discard Bias under Windows is zero. GL Tot : 41/232 MB; Bound is similar to linux. It seems the lack of recognition of the graphic card memory directly affects GL Tot and the Discard alogorithm. This may be why the cache empties so fast...

I don't think that settings.ini trick works, at least not for most people. It changes what's reported in the game in places, but I've never been able to force SL to use more than about 14MB of memory on my card, at least according to the texture console. If I'm up in a skybox it's not so bad because there aren't that many textures around, but on the ground it's low rez city.

Did you know there are commandline options for SL? None of it is particularly useful, but they're there:

usage: viewer [options]
options:
-login <first> <last> <password> log in as a user
-loginuri <URI> login server and CGI script to use
-helperuri <URI> helper web CGI prefix to use
-settings <filename> specify the filename of a
configuration file
default is settings.ini
-set <variable> <value> specify the value of a particular
configuration variable
-user <user_server_ip> specify userserver in dotted quad
-purge delete files in cache
-safe reset preferences, run in safe mode
-noutc logs in local time, not UTC
-nothread run vfs in single thread
-noinvlib Do not request inventory library
-multiple allow multiple viewers
-nomultiple block multiple viewers
-ignorepixeldepth ignore pixel depth settings
-cooperative [ms] yield some idle time to local host
-skin ui/branding skin folder to use

I suspect that the texture memory override isn't being effective because SL still detects the amount of system RAM as 1MB - SL hates to use more video RAM than system RAM where it can avoid it, so maybe that's a stronger rule than the video-memory-size override.

The Linux SL reads /proc/meminfo but doesn't seem to parse the relevant info out of it (whereas it does try to parse /proc/self/status for the Size and RSS, which is quite different).

If someone on this thread is utterly convinced that their video-memory-size override is delivering perfect results, perhaps they can tell us how much system RAM SL thinks they have according to 'About Second Life'.

The video memory size override worked great for me, now I can rez a single texture without it instantly disappearing when I look at the next one. However, the client still won't hold too many fully loaded textures if I turn my back, which is odd considering that I have a 256MB graphics card and my video RAM size is theoretically set to accomodate that.

I have an AMD Athlon XP2600+ and 512MB of system RAM. But according to "About Second Life":

CPU: Can't get terse CPU information
Memory: 1 MB
OS Version: Linux 2.6.15.1 #1 Mon Jan 30 18:32:50 EST 2006 i686
OpenGL Vendor: NVIDIA Corporation
OpenGL Renderer: GeForce FX 5600/PCI/SSE/3DNOW!
OpenGL Version: 2.0.1 NVIDIA 81.78
Packets Lost: 10/1499 (0.7%)
Viewer Digest: 00000000-0000-0000-0000-000000000000

Right Clicking on objects seems to force a texture load. It's faster than just hovering, that also works (windows and linux).

However, the cache empties itself VERY fast...

I am starting to notice this myself, at times its almost like there is no cache at all. As for trying to force textures to load, I havn't found a sure fire way.

Sometimes your only option is to leave an area and come back, everything will be very low res, go straight for what you were trying to see previously and it should load up ok.

As you can imagine, this can make shopping a real nightmare!

Is there any official indication of what approach the SL client uses BY DESIGN to choose which textures to load up first?

Hopefully it's center-screen-first when in Mouselook, and either under-the-pointer-first or closest-to-avatar-first when in 3rd person camera view. In all three cases, that would still leave a lot of room for variation and heuristic improvement through depth-first / breadth-first tradeoffs.

It would be good to know.

Clicking on objects in frustration at the slow loading speeds probably has a larger effect on our adrenaline levels than on viewer operation.

It works for me... I can wait 10 minutes for textures to go sharp, or simply briefly right click on the objects, as I mentioned. Within a few seconds, they go sharp, while I am busily right clicking other blurry lumps.

Hovering with the mouse works too, but slower. This is the only trick I know that helps with AVs.

Ground and linden trees, no clue... eventually they load in detail. Or maybe not...

In any case, the cache emptying algorithm works extremely well

I think the problem is that the game still refuses to use more than 16mb of memory. It will load high rez textures if you force it to, but those take a lot of memory and put it dangerously close to being completely out of memory. The game seems to prefer leaving 6-8 megs free if at all possible, so once you force it to load those high rez textures, the first thing it's going to do is dump them the instant you turn away.

Is there any word on the next version of the Linux client? The client says that I'm out of date, but the download page hasn't changed yet.

Don told me last night to post all bugs and requests here as icculus would be reading through this forum once he started working on the project again.

So my guess would be no time soon with 1.9 looming in the Windows world.