Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 14:07:31



Reply to topic  [ 9 posts ] 
Memory Limit stuff 
Author Message

Joined: 2012-02-09 21:01:50
Posts: 284
Reply with quote
I know this topic pops up every now and then. ;-)

But I am still only half happy with all the changes concerning crashes on sims with tons of avatars and stuff and textures.

One thing that improved a lot: I don't see any distorted or not-loading meshes/textures anymore after logging back into SL after a crash. That was pretty bad some long time ago, a crash usually meant: no more photos cause all was messed up from then. That is resolved, so this is a really great improvement, yay for that!

But still the crashes occur, and before the crash textures start loop loading because the client apparently is unable to keep them all in the memory anymore. The older loop-loading because of textures that never got finished loading seems to be gone, though.

So I am still looking for a solution for this. The problem usually occurs during something like fashion shows... models dress up with a zillion prims and textures and as they walk into view range, memory gets bloated more and more until loop-loading and finally a crash, when the small memory marker on the top bar of the client hits its limit.

Is there maybe a way to discard the oldest textures or something instead of trying load more than the memory allows, and only load the new ones if there's enough space for them?

I mean, models leave the stage and disappear, textures should drop to the bottom of the cache at some time and the client could drop those, finally, to make space for fresh ones?

For me as a photographer, all that is important is the model I am focussed on with the camera (and a bit of background), everything to my sides or behind me could derezz, I wouldn't care at all...

Just some naive loud thinking. Awaiting heavy bashing, cause of lack of indepth-knowledge and bringing up the same topic over and over. :p


Last edited by Tillie on 2015-01-04 17:22:27, edited 1 time in total.



2015-01-04 17:18:04
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Tillie wrote:
I know this topic pops up every now and then. ;-)

But I am still only half happy with all the changes concerning crashes on sims with tons of avatars and stuff and textures.
The viewer shall warn you before the crash happens. Of course, if you ignore the warning and don't relog soon, the crash will occur, by lack of free/non-fragmented memory. If the crash happens without a warning, then either you disabled the memory safety checks, or the safety margin is too small for your (IIRC very) particular setup; in the latter case, try increasing the MainMemorySafetyMargin debug setting by a few dozens of megabytes (it defaults at 160Mb: try 200Mb for a start).

Quote:
One thing that improved a lot: I don't see any distorted or not-loading meshes/textures anymore after logging back into SL after a crash. That was pretty bad some long time ago, a crash usually meant: no more photos cause all was messed up from then. That is resolved, so this is a really great improvement, yay for that!
The result of several bug fixes, both by LL in their code and by me in the Cool VL Viewer code. Also, LL improved greatly the server-side code and the viewer code with HTTP pipelining, which helps a lot.

Quote:
But still the crashes occur, and before the crash textures start loop loading because the client apparently is unable to keep them all in the memory anymore.
Try disabling "Advanced" -> "Rendering" -> "Textures" -> "Boost attachments textures". This is a feature which is exclusive to the Cool VL Viewer and that I implemented ages ago to solve the old issue with some attachments textures not fully loading and staying blurry. However, nowadays, with the silliness of some creators, you can see more and more attachments with tiny prims bearing 1024x1024 pixels textures for each face (which is plain stupid and consumes a shitload of memory when fully loaded); with materials this can even get much worst since each face can have two more textures (for the specular map and the normal map)...
Even though I made it so that the boosting gets suspended when the textures discard bias reaches a certain threshold (i.e. when textures memory gets low), it still causes all the attachment textures of the avatars present before the threshold gets reached to be fully fetched (i.e. the full raw textures get loaded in memory and cache, even if the rendered texture gets resized down to a lower LOD after the threshold is reached): this is for example the case when you TP into a crowded place (all the avatars there get their attachments textures fully fetched).
I might change the default for this setting to off in the future, especially since the newest calculations for the "importance to the camera" (which governs the textures LOD) is much better than what it used to be in the past.

Quote:
The older loop-loading because of textures that never got finished loading seems to be gone, though.
I implemented full UDP fetch fallback for textures failing to fully load via HTTP fetches...

Quote:
So I am still looking for a solution for this. The problem usually occurs during something like fashion shows... models dress up with a zillion prims and textures and as they walk into view range, memory gets bloated more and more until loop-loading and finally a crash, when the small memory marker on the top bar of the client hits its limit.
Again, you should get a warning before the limit is reached (see above).

Quote:
Is there maybe a way to discard the oldest textures or something instead of trying load more than the memory allows, and only load the new ones if there's enough space for them?
This is already the case in the Cool VL Viewer and has been the case for years... One of the features related with the memory safety checks and discard bias computation is that when the memory gets low, the viewer will force an immediate and full re-evaluation of the textures priority (instead of just re-evaluating a fixed amount of textures per frame); this can be seen happening as the textures will suddenly all become blurry then quickly reload at the proper LOD again in a matter of seconds (but without looping forever) and at this point you will see the memory usage indicator dropping since all the textures not in direct view will have been unloaded from memory.

Quote:
I mean, models leave the stage and disappear, textures should drop to the bottom of the cache at some time and the client could drop those, finally, to make space for fresh ones?
For me as a photographer, all that is important is the model I am focussed on with the camera (and a bit of background), everything to my sides or behind me could derezz, I wouldn't care at all...
The new objects caching scheme as implemented in LL's recent viewers and in the Cool VL Viewer v1.26.12 already takes care of wiping out the memory from the objects (and, after a small delay, their associated textures if they are not in use by other, visible objects) after they leave the camera field of view (FOV). The old code was keeping all the objects, so the new code makes for a better memory management. Also, I improved the algorithm to make it adaptive to the available memory: the less free memory, the faster the objects get wiped out after they disappear from the FOV.


2015-01-04 19:09:16
Profile WWW

Joined: 2012-02-09 21:01:50
Posts: 284
Reply with quote
Yah, I get a warning. But not much I can do. Or should I TP out to a deserted place with low/zero prims, check that the memory usage drops and then TP back?

Will check the setting changes you mentioned. :)


2015-01-04 19:17:06
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Tillie wrote:
Yah, I get a warning. But not much I can do. Or should I TP out to a deserted place with low/zero prims, check that the memory usage drops and then TP back?
This may help, but only if the problem is with free memory and not with a fragmented memory (as objects, textures and vertex buffers get loaded and unloaded, the memory address space gets more and more fragmented over time, till large allocations fail to fit any of the small, fragmented free blocks, even though there may be enough free memory in total).

Your best bet is therefore to relog...

The only definitive solution for this memory issue will be 64 bits viewers (when LL will decide to provide support and pre-built libraries for them...).


2015-01-04 19:27:15
Profile WWW

Joined: 2011-12-13 14:11:38
Posts: 186
Reply with quote
Are there general rules or useful settings that might help keeping the memory usage low? I tried a few like 'Compress textures', or turning off 'Boost attachments textures' as you suggest, or lowering the number of non-impostor avatars, but they don't seem to help a lot… Not sure why, but there are some places where I used to go without problems, places that are always quite crowded, and now I can rarely stay there for very long: I'm getting memory warnings quite quickly, and I have to go, or I do crash.
Since I'm doing photos and my computer can handle it, I was almost always on 'ultra' graphics settings, and I thought it might have been because of that. But I went down to just 'high' (which is the recommended setting, or at least the one I get when pressing the 'Recommended' button), and it didn't bring any noticeable change… So I'm wondering now if I can do anything to prevent the memory from filling up in 10 minutes in places where there are more than a dozen people around…


2015-01-05 21:24:05
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
ErikaThorkveld wrote:
Are there general rules or useful settings that might help keeping the memory usage low? I tried a few like 'Compress textures', or turning off 'Boost attachments textures' as you suggest, or lowering the number of non-impostor avatars, but they don't seem to help a lot… Not sure why, but there are some places where I used to go without problems, places that are always quite crowded, and now I can rarely stay there for very long: I'm getting memory warnings quite quickly, and I have to go, or I do crash.
Since I'm doing photos and my computer can handle it, I was almost always on 'ultra' graphics settings, and I thought it might have been because of that. But I went down to just 'high' (which is the recommended setting, or at least the one I get when pressing the 'Recommended' button), and it didn't bring any noticeable change… So I'm wondering now if I can do anything to prevent the memory from filling up in 10 minutes in places where there are more than a dozen people around…
Some places got crippled by over-sized textures and some avatar attachments have been recently created that are using a crazy amount of memory (some mesh swaying tails, for example, that cause the viewers to reload over-sized textures and reallocate vertex buffers 10 times a second as they achieve the swaying movement by alternatively turning the numerous and over-detailed (i.e. with too many vertexes per mesh) mesh child prims transparent... This causes a *massive* memory usage (300Mb per swaying tail !!!) and large slow down of the FPS rate (allocating and de-allocating vertex buffers and textures each frame on a gazillion of mesh faces takes time...), as well as a quick fragmentation of the memory address space over the session.

You may use the new "RenderAutoMuteMemoryLimit" setting to automatically visually mute avatars using an excessive amount of memory because of insanely badly designed attachments. Alas, that feature is far from perfect and will not free the whole memory associated with these attachments. But at least, it entitles you to spot the problematic avatars and attachments, and you still can de-render the said attachments (after disabling the auto-muting, alas). I'll perhaps try and improve that feature to turn it into an auto-derender-attachments one, but it's not trivial, because of the way attachments are rendered (the "spatial partitions" used by the renderer do not correspond to single attachments).


2015-01-05 23:35:28
Profile WWW

Joined: 2012-02-09 21:01:50
Posts: 284
Reply with quote
RenderAutoMuteMemoryLimit sounds like a super cool feature... trying! :D

But no idea, what is a suggested value for that? Is 32MB too hard or too low? :-o

And which value for TextureMemory again? It defaults to 512, and there is a setting of 0 for autodetect...


2015-01-06 08:32:32
Profile

Joined: 2011-12-13 14:11:38
Posts: 186
Reply with quote
Tillie wrote:
RenderAutoMuteMemoryLimit sounds like a super cool feature... trying! :D

But no idea, what is a suggested value for that? Is 32MB too hard or too low? :-o

Advanced -> Rendering -> Info displays -> Attachment bytes, then look around. ;) With 32MB, I guess you won't derender a lot of people… I tried, the max I could see was 12MB… and it was me. :oops: Mesh bodies aren't helping for memory usage, it seems…


2015-01-06 09:36:15
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
The idea of RenderAutoMuteMemoryLimit is to visually mute avatars with excessively badly designed attachments (many "modern" attachments are poorly designed, but some are worth griefing objects...). A 64Mb limit per avatar seems reasonable.


2015-01-06 10:39:19
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 9 posts ] 

Who is online

Users browsing this forum: No registered users and 20 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.