Kirstens Viewer has been Updated!

[Sassy Kenin]

(Warning this is not a linden lab viewer & no longer offered on the 3rd party viewer list..User beware)

She has updated the viewer after all these years. Her blog & Download

(Warning this is not a linden lab viewer & no longer offered on the 3rd party viewer list..User beware)

[Pussycat Catnap]

Well that was unfortunately bad timing... SL just had a major update with EEP... so any recent viewer updates are now out of date already.

Hopefully it will get another update very soon.

[KirstenLee Cinquetti]

Yup impeccable timing :)..... have now done the EEP currently 6.4.1 base code

And the viewer has completed all its re-certification steps and has been activated on the TPV list.

Enjoy!

[Indigo Fae]

3 hours ago, KirstenLee Cinquetti said:

Yup impeccable timing :)..... have now done the EEP currently 6.4.1 base code

And the viewer has completed all its re-certification steps and has been activated on the TPV list.

Enjoy!

Welcome back ! 

 Loving the updated viewer. the EEP  is alot of fun to play with. Very stable and smooth viewer. Big fan here. Cheers. 😀

[Alec Kaestner]

This makes me soooooo happy!

[Kieran Dallas]

After hearing alot about this viewer was awesome back in the old days. I am excited to be using it. I'm not disappointed at all. the 1416 build seems to heat up my 1080 ti card more then other viewers  but the graphical fidelity and smoothness is worth it to me. I see why machima and photographers raved about the viewer. I hope to see more builds. KL has a fan in me. Big thanks !

[iceing Braveheart]

On 4/29/2020 at 12:16 PM, KirstenLee Cinquetti said:

Yup impeccable timing :)..... have now done the EEP currently 6.4.1 base code

And the viewer has completed all its re-certification steps and has been activated on the TPV list.

Enjoy!

how much video card memory does the viewer support?

[Solar Legion]

19 minutes ago, iceing Braveheart said:

how much video card memory does the viewer support?

As much as any other Viewer: However much your system can spare.

You have been repeatedly corrected on your assumption concerning the Memory Buffer setting - stop asking about it.

[iceing Braveheart]

19 hours ago, Solar Legion said:

As much as any other Viewer

seems pretty pointless then, 512mb same as official or firestorm 2gb limitations?

19 hours ago, Solar Legion said:

However much your system can spare.

haven't found a viewer yet that can utilize my system

19 hours ago, Solar Legion said:

You have been repeatedly corrected

not once

 

Edited June 20, 2020 by iceing Braveheart

[Solar Legion]

The 512MB and 2GB limits have nothing whatsoever to do with your VRAM as has been pointed out to you repeatedly.

So yes, you have been repeatedly corrected on your misconceptions.

You are not asking a simple question, you are refusing to listen to the answers you have been repeatedly given over the course of more than two years, at the very least.

At this point you are either trolling or simply incapable/unwilling to understand the information that you have been presented with (again, over the course of at least two years).

[Lyssa Greymoon]

14 minutes ago, iceing Braveheart said:

seems pretty pointless then, 512mb same as official or firestorm 2gb limitations?

The texture cache limit is 512MB.

[NiranV Dean]

On 6/20/2020 at 5:41 AM, Lyssa Greymoon said:

The texture cache limit is 512MB.

The 512MB shown isn't even correct. 512MB as setting corresponds to something around 1GB. LL never allowed more as far as i can tell, i "guess" that 1GB probably allows like ~2GB and thus 2GB in Firestorm probably allows like 4GB or something. I can only guess how much the number actually corresponds to based on the small sample between 32 and 512MB thats available.

[Profaitchikenz Haiku]

Can you clear up a bit of confusion in my mind, the texture memory in question is not that on the graphics card itself but a block of RAM allocated for the graphics card to use, a bit like swap memory? I'm not even sure why a GPU with 5GB onboard RAM even needs such system memory?

[NiranV Dean]

RAM and VRAM are two different things.

RAM is your system memory and used by your OS and all applications to save and load information from temporarily while they are running. It can be basically anything.

VRAM is your graphics card memory which is primarily used for rendering and is filled with textures, which is why most people call it texture memory.

SL generally requires 300-1000MB system memory to startup and run, independent of anything else. This number will raise with more information being stored, meshes, textures, data for the UI and so on. In busy places you'll easily see it go up to 2GB or more. SL in addition requires texture memory too from your graphics card, starting at 100-200MB for the Viewer itself and going up to 2-3GB on average on a lot of regions which aren't empty and have a handful of avatars. In some extreme cases, especially bad regions with a lot of badly optimized textures and avatars this number may even exceed 3GB and go all the way up to 4GB or possibly more. If you can't give SL enough texture memory it will start throwing out textures it thinks aren't needed, in a place where everything around you is the cause for your texture memory overflowing you'll see textures start going blurry before loading once again, followed by going blurry again, this cycle may continue forever and even worse will basically put a dent into the Viewer possibly "breaking" texture loading until you relog, the moment you start "texture trashing" once, the Viewer may stop loading textures fully and will require a relog to fix. This is a very common issue and you as user can't do anything about it other than raising your texture memory setting and hoping it wont require more than you've set which is the case, most of the time.

The texture memory setting is just a value that tells the Viewer how much memory it is allowed to allocate for textures although its not an exact number as i've already mentioned in my previous post. Not sure why that is but that's just how it works. I can guarantee you though that 512MB (~1GB) is not enough for almost everything in Second Life. Most people's own avatar already fills a quarter to half of that alone. Not to mention the HUDs some people wear that will fill your measly 1GB instantly.

[Ardy Lay]

Damn the torpedoes! Set Full Res Textures = TRUE!

[Profaitchikenz Haiku]

7 hours ago, NiranV Dean said:

The texture memory setting is just a value that tells the Viewer how much memory it is allowed to allocate for textures although its not an exact number

Thanks for your helpful explanation. So, somebody like me who's stuck with an oldish Dell that can't have more then 4GB onboard RAM is stuck, even if I get a GPU with as much or more RAM than the board.

Your point about badly-optimised regions bears out my experience, I can get around loads of places Ok, some of them cause a Graphics card driver crash which to some extent I can stop by reducing this "texture memory" setting to half the suggested value, plus turning off ALM. I can only assume therefore that the setting does have some purpose in protecting part of system RAM from being swallowed up by people's love of 1024x1024 textures for the diffuse, bump and speculars.

Kirsten's latest s23 does a good job (So, by the way, does your Black Dragon), although I wish there was still the 32-bit option that S22 allowed.

 

 

[NiranV Dean]

9 hours ago, Ardy Lay said:

Damn the torpedoes! Set Full Res Textures = TRUE!

And this ladies and gentlemen is the reason why so many people with decent hardware run at sub 5 FPS still.

Do NOT set Full Res Textures to TRUE unless you are absolutely hellbent on having all textures loaded fully regardless of your GPU even being able to keep all the textures loaded. The moment your VRAM is full you'll hit a brick wall and your GPU will start texture swapping which will cost you your performance, if any is even left by that point.

I'd only ever use this option if you absolutely have to for a very specific super resolution picture with simply too many resolution textures on screen that you cannot normally handle and only if you are willing to do a relog right after you're done with this option disabled again.

5 hours ago, Profaitchikenz Haiku said:

Thanks for your helpful explanation. So, somebody like me who's stuck with an oldish Dell that can't have more then 4GB onboard RAM is stuck, even if I get a GPU with as much or more RAM than the board.

Your point about badly-optimised regions bears out my experience, I can get around loads of places Ok, some of them cause a Graphics card driver crash which to some extent I can stop by reducing this "texture memory" setting to half the suggested value, plus turning off ALM. I can only assume therefore that the setting does have some purpose in protecting part of system RAM from being swallowed up by people's love of 1024x1024 textures for the diffuse, bump and speculars.

Kirsten's latest s23 does a good job (So, by the way, does your Black Dragon), although I wish there was still the 32-bit option that S22 allowed.

Lowering your texture memory has the side effect that less textures are allowed to be loaded into VRAM which means less textures are loaded into RAM as well since the Viewer doesn't load as many textures fully as it usually would, this saves some RAM. Although i'm unsure whether ALM does save RAM noticeable amounts outside of materials (specular and normals) being turned off. With only 4GB RAM however, every MB you can save counts i suppose.

The 32bit version has been deprecated officially because at this point in time, there is no longer any point running a 32bit application, especially in a open ended application like Second Life where memory usage greatly varies. Absolutely everyone should have a 64bit OS by now (should have 10 years ago, should have starting with XP already...) and even with just 4GB RAM you see a slight improvement with a 64bit OS because it can fully utilize 4GB out-of-the-box whereas it previously required some tricks. However 64bit applications are also notorious for using up more RAM which makes it harsher for 4GB RAM OS's to run these applications if said application can easily spike up to 2-3GB alone.

If you experience out-of-memory crashes you might want to lower your draw distance and keep max visible avatars and the jellydoll complexity settings somewhat low and only selectively render people if necessary. Avatars are one of the biggest memory hogs, you should only ever have a handful visible at max with your available memory.

Also regarding the texture memory information, note that Black Dragon works differently. What you set is what you get. There are no hidden scalars. Hence why BD offers two sliders instead of one as Second Life internally has two texture pools effectively keeping all textures twice in VRAM... to ease managing it i added an automatic memory management which basically simply takes as much as currently needed plus a bit extra while leaving a bit room for the OS and other stuff if approaching your GPU's max VRAM. The reason it doesn't just do "give me everything" is because setting texture memory higher/lower has shown having direct impact on your framerate in the past (as well as some reported crashes if set above 3992MB). Whether this impact is due to less textures being loaded or actually a direct impact due to the bigger allotted space is hard to tell but i went for the better-safe-than-sorry option. BD is also the only Viewer currently known to me allowing straight up using up to 8GB VRAM (total) since apparently LL doesn't see a need it in and Firestorm refuses to allow using more because it would "support" bad content practices, specifically people bloating your texture memory with even more unnecessary 1024x1024 textures (which evidently was the case long before we started allowing more VRAM usage)

Edited June 23, 2020 by NiranV Dean

[Ardy Lay]

Sometimes a reenactment of the Battle of Mobile Bay is required to get that snapshot.

Sometimes it breaches and sinks but usually not.  Even when it does, a relog is not needed, as the discarding resumes if I normalize that setting before I get a HEAP allocation fault.  I would certainly prefer some middle ground but am stuck with LL’s LOWFER memory settings.

Edited June 23, 2020 by Ardy Lay

[NiranV Dean]

12 hours ago, Ardy Lay said:

Sometimes a reenactment of the Battle of Mobile Bay is required to get that snapshot.

Sometimes it breaches and sinks but usually not.  Even when it does, a relog is not needed, as the discarding resumes if I normalize that setting before I get a HEAP allocation fault.  I would certainly prefer some middle ground but am stuck with LL’s LOWFER memory settings.

The continuing discarding IS the reason you relog.

[Ardy Lay]

1 hour ago, NiranV Dean said:

The continuing discarding IS the reason you relog.

Nah, it stabilizes and then goes back to normal.  No need to relog.

[NiranV Dean]

2 hours ago, Ardy Lay said:

Nah, it stabilizes and then goes back to normal.  No need to relog.

Lucky you, in all my years i've never seen texture loading fix itself when it broke once.