Cool VL Viewer forum

Yes, I know that, but, quoting you:

Well, I definitely have more than 4 GB of RAM… And I once checked the memory consumption in a place that was just packed with people with textures all over the walls, and I don't think it went over 2 GB… So on a little set like that, how on Earth can it cause such problems?

Some news about that: just for a test, I made an alt for myself with basically nothing in its inventory at all. And I found out this: in a place where I'm getting the issue, if I log my alt there with Cool VL Viewer, same settings, I don't get the problem: textures in my field of vision are usually fine, and even when textures are blurry when I turn round, they don't go in a loop, they just rez. I even did the test with the two avs logged in at the same time and at the same place: I was having texture issues with my main, not with my alt. I couldn't do the test with both logged in Cool VL Viewer though, since Macs refuse to launch a new copy of an application when it's already running. So I was logged in with Singularity on my main, and Cool VL Viewer and my alt. And when I logged both out, and logged back in on my main with Cool VL Viewer, the texture issue happened again…
So could it be the inventory? I guess it does take some space in memory, but enough to cause this? I don't have a huge one, it's like 50000- items.
I also checked the memory Cool VL Viewer was using while I was having the issue: the activity monitor was reporting less than 700MB… Quite far from the 4GB limit…

Well, anyway, I have a workaround for photos now: I can take them with my alt. Might not work for everyone though: with my 32 GB of RAM, running two SLs is a piece of cake. I guess it might be more problematic for other people.

I doubt it's inventory-related, but it could potentially be something your main avatar is wearing and that causes a huge memory consumption (crazy mesh ?...).

I don't know Macs, but most memory reporting tools in Windows and even Linux are often inaccurate (what counts is the total mapped virtual memory, not just what has been allocated in the heap, for example... it must therefore include the program code, the mapped DLLs, memory-mapped files, etc, etc...). For a more accurate figure, use the viewer itself: "Advanced" -> "Consoles" -> "Info to Debug Console" -> "Memory Stats".

Not sure if it's "crazy" or not, but I do have a mesh body, yes. But when I logged my alt, it had my main in its field of vision, so wouldn't it impact it too? And besides, I'm sure I was having this issue even when I wasn't wearing it.

Thanks for that. I just tried, it seems the difference between what the viewer sees and what the Activity Monitor reports is not so big: the viewer says 714 MB when the Activity Monitor says 688 MB… Not having the issue at the moment though, I'll try again when I get it.

Thank you!

Well, it wasn't the mesh body… It was its HUD. I was at a big party today, people all around, and at first, with the HUD on, textures were looping like crazy. Someone told me about a warning sent by people from Firestorm about the HUD for this mesh body that could cause this kind of issue. I tried, I detached it. The problem just disappeared: textures are now loading correctly, no more loop… And that explains why my alt didn't have the issue: it didn't have this HUD on.
So my advice to people getting this issue: detach all your HUDs, and more generally as much of your scripted attachments as you can: it seems a mistake in a script can cause this texture loading loop.

That must be a very badly designed HUD... HUDs get their textures loaded at 0 discard level (i.e. at full resolution), so if that HUD contains a gazillion of ultra-high resolution textures (2048x2048), that could indeed explain it...

Hello everyone,

It's definitely not the scripts, Erika. It's textures. I have been fighting this issue for some time now, and it's simply an exhaustion of texture memory due to an excess of high-resolution textures. They don't even have to be clearly visible. First the discard level rises to 5, then the thrashing starts.

Some "clever" builders these days think it's good practise to put all textures either into the HUD or (even worse) an item itself, just so that a texture change will seem instantaneous when performed (as the textures are already loaded and will appear immediately). I won't name and shame in public, but at least one quite popular RLV restraint from one of the major merchants does this. At least it's mod, so I could fix it for myself.

Also, some very recent mesh clothes I bought (also from a renowned vendor) did this in the companion HUD (by putting all the (1024x1024!) textures on the cubes serving as buttons -- several dozens of them.

Items like this will literally eat hundreds of megabytes of texture memory, as can be easily observed in the texture console (Ctrl-Shift-3). Next time you are having issues, open it up and check the memory used, and the discard level. Chances are it will be at 5.

I presume the issue may be aggravated by the way LOD calculation works, so a higher resolution may play a role here, and of course draw distance and some of the LOD debug settings that are very popular "to make things look right". But I am sure Henri can shed some more light on this.

Love,
Lia

Thanks for the answers Henry and to the other posts a great wealth of info. They are exactly what I was experiencing basically in all viewers some worse than others I assume because of various settings they have different from each other. I use GPU-Z when testing and some SIMS can load almost 2gb into VRAM mostly all of the MESH variety as one of my testing areas is a Nightclub with 50 or so avatars dressed to the Max. I know the Vram setting in the viewer's debug settings is limited to 512 however version 4.4.2 Firestorm for some reason the Max can be raised. So I have tried 1024mb and the viewer experience is MUCH smoother for my purposes which is Machinima and maybe not recommended for the average usage. I'm still having issues with some specific Mesh (possibly due to the creator) usually shoes and hair not appearing at all and then it's a crap shoot whether a relog will correct it. That is with the Firestorm Viewer so downloading CoolVL today to check the performance once again. Anyone I meet with issues I generally point them this way to try your viewer since it is definitely faster.

regards
Ormand Lionheart

The 512Mb limit is not as much a problem with the VRAM (which is nowadays way less limited than in the past, even if that VRAM must also be large enough for VBOs, frame buffers, vertex buffers, etc, and not just textures), but with the fact that each texture held in VRAM must also be duplicated (most often twice: as compressed and raw textures) in CPU RAM. With the 3Gb (4Gb when running on a 64bits OS) address space limit imposed to 32bits applications, increasing the texture VRAM beyond 512Mb only causes to reach sooner that limit and you crash as a result.

LL recently attempted (in one of the RC viewer branches) to raise that 512Mb limit, but they quickly reverted the commit and went back down to 512Mb, most probably because of the virtual address space issue.

Of course, when a viewer is compiled as a 64bits application (which Firestorm may be: AFAIK they have got at least one such version), the address space is not an issue any more and the texture VRAM limit may be raised. The problem is that 64bits pre-compiled libraries are not available from LL and even if you compile your own, you'll run into troubles with media support... See also the other threads about 64bits support (compilation tool chain issue under Windows, etc).

Yes I was using the 64 bit viewer so maybe I didn't have as much problem also depends on how much Vram you have I assume. So what I noticed was more Vram was used and I assume more textures were being loaded there? So if you have the limit at 512 (which LL says is a soft limit) the textures get offloaded to the SL cache or system Ram? which led to some texture swapping/ reloading? Anyway installed the latest from Cool VL and at first low performance and GPU-Z showed vid card running at a 1/3 of capabilities due to Windows 7 not recognizing SL as a "game" so power mode is "preferred". This is common on my system with SL. So made a game profile in Nvidia Control Panel and got some really nice fps performance in Euro Club with 30 avi's (50fps). Also set the profile to no AA or AF and used FXAA anti-aliasing instead which shows no jaggies. The other thing I noticed is on the same SIM Coll VL using about 40% less Power Consumption so less heat as well(maybe I have Firestorm configured differently. Not sure of my Mesh issues that crop up yet but that was in a SIM with 86 avatars although I did derender the majority of them.

I do find the environment editor in V1 style MUCHO better than the V3 version and even Phototools version. Why they changed that is beyond reason.

regards
Ormand