Cool VL Viewer forum

Hey there.
First of - I'm so glad that cool viewer is still around. I took quite a long pause from SL and was using another viewer but cool viewer is just the coolest and best performing one for my needs. Thanks!

But there is one thing that is not so good at least for me.
I'm a SL Live Musician and Singer and as I'm routing all my Live Music Setup through my DAW, using a great piano sound that is sucking on my cpu quite heavily, my old Computer is at its performance edges. I'm so happy that cool viewer is still very fast and not so heavy on cpu like the others.
But unfortunately there is one "bug" that is not so perfect for me: when I'm zooming in or out in SL or when quite some people join or move in the venues I get really really huge cpu spikes for some seconds. That is not the case with e.g. firestorm viewer.
Do you have any ideas why happens?

Beside of that I'm still in love with the Coolest Viewer )

Thanks in advance!
Frank

The viewer attempts to utilize your CPU available cores at the highest level whenever it rezzes new objects and avatars (mesh fetches) and fetches and decodes the corresponding textures: when you cam around, rezzing happens and causes a CPU usage spike; this is in no way a "bug" but the desired behaviour. This ensures the fastest rezzing speed and things go much easier on the CPU once everything is rezzed.

If you want slow rezzing, you may disable or tone down several features:

• In the "Preferences" floater, "Cool features" tab, "Miscellaneous" sub-tab, you may adjust the number of images decode threads (defaults to 0 which means auto and depends on the number of cores your CPU got). To revert to other viewers' behaviour (just one decode thread), set it to 1 and restart the viewer.
• In the "Advanced" -> "Rendering" -> "Textures" menu, you may toggle the "Boost fetches with speed" (camera speed) and "Boost proportional to active fetches": disabling them (though, they are normally off by default) will revert to the standard texture fetch decode updating (sparser, meaning less decode updates per frame).
• In the "Preferences" floater, "Network & web" tab, you may adjust the number of simultaneous textures and mesh requests. The lesser, the slower (and the less network bandwidth used), but the less CPU load while rezzing.

Many thanks for your fast and very helpful reply Henri!! I'll try that today.

hey there!

Unfortunately I have to come back to that heavy CPU-Spike topic, this time when new Avatars arrive in the radar where I'm singing at.

I know the problem is only because of my pc and cpu are really old but I managed to still be able to have a good experience even when playing my heavy on cpu Piano vsti's so far. The thing is, that my machine is working on the edge when I do my live shows. That is one important reason (among others of course) why I'm a happy user of the really Cool VLViewer. Merci beaucoup Henri !!!

Since Version 1.30.7 (I think) I do have again those heavy CPU usage of the CV what was not the case after my tweaks when it happened the first time. I checked already the proposed tweaks from the older thread (http://sldev.free.fr/forum/viewtopic.php?f=6&t=2187) but that didn't really help so far on the search of the maybe last 15% that avoid me from having strong audio crackles while playing my piano.

My questions are:
- What have you changed that would cause that in my specific scenario to make me have a look at it?
- Would http pipelining turned off help in my case? ( I don't know what that is..)
- Would it help to turn OpenGL off? Currently I have OpenGL Profile clicked active. Changing the OpenGL Worker threads didn't help resolving the heavy cpu load that I need to avoid (and during my shows it's not important for me to see the avatars.. in fact.. I only zoom to the stage. so they only get rendered in the background where I cannot see them.)
- Image decoder threads .. I just forgot and couldn't find how the logic is behind it. I'm having a 4+4 i7 chip (i7 860 @ 2.80Ghz). What does in the CV mean 1 thread? 1=1 or 1=1+2 (2=1+2 or 2=1+2+3+4)

Thanks again in advance for your help!

Same reply as I did before (I also merged the topics, since they deal with the same "issue").

The Cool VL Viewer is optimized to use as much CPU power as it can whenever it needs to rez new things (such as objects and avatars appearing in your camera FOV, or incoming avatars). It is therefore totally normal and the expected and wanted behaviour, that it raises your CPU usage to almost 100% to rez as fast as possible. And the more the time passes and as I will keep squeezing the last CPU clock in my code, the more the viewer will use your CPU to make everything rez and display faster.

As I already explained above, you may degrade the performances of the viewer to avoid this: limit the number of threads (one image decoder thread only, no shared GL worker thread, no media plugin read thread), disable all texture fetch boosting features, reduce the maximum number of simultaneous mesh and texture requests, etc...
When using the frame rate limiter (which is also a good way to reduce the CPU usage), you may also disable the extra image updates the limiter is doing by setting the new "MaxExtraImagesUpdates" debug setting to 0.

As I also already explained, you may use your OS thread affinity settings to limit the number of CPU cores (virtual (SMT) cores or full cores, depending on your CPU: your i7 860 is a 4 full cores, 8 virtual cores CPU, and programs will treat it as a "8-core") used by the viewer, and reserve others for your near-real-time audio application; however, do not expect good results under Windows (which is NOT a real-time OS, by far !), and do not expect your old CPU to perform as well as a modern one could do.

If I were you, I'd buy another, cheap or second hand PC to run just your virtual piano, and reserve your current PC to all other tasks (including running the viewer).

Thread affinity, which Henri mentioned, works quite well at least on my Linux rig. I also use the frame rate limiter, shorter draw distance, limited particles and avatar impostors and a variety of other settings even though I have a robust machine. These may reduce the 'beauty' of the world but if you are performing, how much of that do you really need? You could travel to a heavy attended event/region, when you aren't performing, to come up with the settings that work well for your hardware. Apply those when performing but use more 'rich' settings when you are not. Obviously my opinions/experiences. Your mileage may vary.

Linux is not Windows... Yes, the viewer is much snappier and runs "smoother" under Linux, and yet other programs can run along it without suffering from the high CPU usage. I often compile new viewer binaries while running the current viewer, and the CPU is loaded at 100% all along: with the frame limiter on at 60fps and 2 cores reserved for the viewer main thread + GPU driver threads, I often do not even have any fps slow downs.

Yes, no truer words and why I no longer use it.
You must have a better machine than I then. I have affinity set for 2 cores and frame rate limited to 60 as well, because I don't have any monitors that can do more. I still regularly encounter areas and specific camera directions that cause frame rate to drop and stay low, even after remaining stationary. It's not that big of a deal because it's still in the 30/40s. I often just attribute that to more 'complexity' in the direction I'm facing.

I was not pretending keeping 60fps while moving around, of course (since then, the viewer does see a drop in the fps rate until everything is rezzed), but just staying in a place in SL while I perform a compilation.

I think my periods of lower frame rate, even while stationary, could also be attributed to having full shadows on. I have noticed that when the sun (maybe even moon) angles are lower and shadows are longer, frame rate is reduced. Again, nothing that I haven't adapted to. The viewer still performs very well on my semi-modern system with an AMD Ryzen 7 3700X, NVIDIA GTX 1080 Ti, 64Gb RAM (which I use to set up a ram disk for viewer cache).