Cool VL Viewer forum

Hello Henri, hello all,

I really like how Cool VL Viewer now has a memory usage management feature, looks like it does make it crash much less. However, sometimes, I'd like to have a little more options than just having it on or off. This would be especially interesting for people doing photos or movies in SL: having the viewer crash is always bad, but having it taking actions at unepxected moments can be pretty bad too. So here is my idea, which is just a variation of what already exists. I think it would be nice to have 4 levels of memory usage management:

• First one: have it off. This is the same as unchecking 'Memory usage safety check' today.
• Second one: just have the memory usage indicator, but no warning and no action taken when the memory usage gets too high. This would allow to 'manually' monitor the memory usage, but would avoid having things displayed or actions taken, which is great when shooting a movie for example…
• Third one: have the memory usage indicator, warnings on what can be done to reduce it, but no action taken. This would be nice when shooting photos: you know there's a problem, how to possibly solve it, but it doesn't change your camera angle.
• Fourth one: have it fully on, with warnings and automatic actions. This is the same as having 'Memory usage safety check' checked today;

What do you think about it? Is it a good idea? Would it be easy to do that? I think it could really be helping a few people…

Thanks!
- Erika -

I don't like this idea at all: it's too complicated and it's inefficient (you will not have the time to react before the crash happens: the algorithm must react fast and in real time, also taking into account the inertia resulting from the fact there's a significant delay between the moment a texture is requested with a given discard level and the moment it is fully downloaded and decoded: to reduce this texture's discard level, the former request must fist be completed, meaning there is a delay between the moment you increase the discard level and actually see the memory consumption diminishing).

When on, the algorithm should prevent any crash related with virtual memory space exhaustion to happen. If you disable it, then you're left with the behaviour of all other viewers that will invariably crash at some point. Of course, if you insist on caming around after the viewer reset your camera and told you it's about to crash if you continue doing so, then you will crash... Instead, just wait for the memory indicator to turn back to green, then you can again cam around and increase your draw distance.

If you wish to avoid seeing the memory consumption kicking in too soon, you must adopt settings that are suitable for your system. If you got less than 4Gb of RAM, then you will likely see it kicking in anyway, for mesh viewers are memory-hungry; this is not only due to mesh support itself, but also to the new physics parameters support, the necessary memory alignment of every data structure on 16 bytes boundaries to allow the use of SSE2, and the memory overhead resulting from the use of tcmalloc.

Even on a 4Gb+ RAM system, things such as a 512m draw distance in a crowded and/or heavily textured area will likely make the algorithm kick in to prevent crashes. I recommend a 256m draw distance (which is more than enough in most cases).

One setting that is often overlooked is the "Texture Memory" (in Preferences -> Graphics -> Hardware Options): 512Mb (in the graphics card) corresponds to 1Gb of memory consumptions in the viewer (which may even overshoot !). Lowering this setting might well help, at the cost of more blurry textures on far objects.

Also, on systems with 4Gb of RAM or less, it's usually best to keep "Allow Swapping" on (the algorithm will then kick in later, but still in time to avoid crashes).

Finally, do make sure that your system is properly configured to let applications use up to 3Gb of virtual space (on 32bits Windows, the default is only 2Gb). See this message about how to set this.

OK, I get your point, but that brings me to something else… You say:

Well, this is not what I'm seeing at all, hence my request. Basically, when memory usage safety check is enabled and after it resets my camera, I can continue camming around without any other major problem than a slow down and blurry textures. This is why I made the request: for me, it really looks like I have some time to decide wether I want to reset my cam or not. But if you say that for you, the algorithm must kick in at once to prevent a crash, then of course, what I asked for wouldn't work…
So the behaviour I'm getting might be because I'm on a Mac. It seems the computed memory usage is not really acurate there. I know you can't test on a Mac, so I'll ask someone who can (namely, Guru ) to see if there isn't any problem. I'm not totally understanding how this is computed, but I already had the curiosity to look at how much virtual memory Cool VL Viewer used when it said its usage was like above 90% or even 95%, and I saw figures like less than 2Gb, when I have a total of 4Gb… Not really sure this is meaningfull, but with what you say here, I might have found a little problem.
Well, for now, I'll keep the memory usage safety check off, as it seems it kicks in way too early and end up being more annoying than useful. I turned it off a few days ago, and I didn't see Cool VL Viewer crash more than usual, so I guess it's quite safe for me. And well, this is SL, I've been using other viewers for years, I'm used to the crashes.

Thank you very much!

Only 3Gb of virtual space can be addressed out of the total 4Gb (this is referred as the "memory split", which is normally 3Gb/1Gb (application/kernel) on Linux and probably the same on MacOS-X). Among these 3Gb, a few hundreds of Mb are used by the binary (main program but also all the libraries it loads). There is also the problem that over time and as textures and data structures are allocated and deallocated by the viewer, the virtual space gets fragmented, meaning the actual available space is less than the 3Gb. In the end, you can count on a maximum of 2.2 to 2.4Gb of usable virtual space, and the algorithm does account for this all.