New Linux enhanced viewer: The Cool SL Viewer

There is no patch in the Cool SL Viewer affecting this part of the code (so it would be a bug in the official sources for v1.20.10.0), and I cannot either reproduce it here... Sorry.

Please, folks, only report here bugs that are actually specific to the Cool SL Viewer... This new "feature" is also showing with the official 1.20RC8 viewer, so please report the bug on the JIRA instead. Thank you.

Also, like I already wrote both on the website and in this forum, the Cool SL Viewer v1.20 is an _experimental_ viewer. For serious use, please run the Cool SL Viewer v1.19.0.5, which is the stable version.

The Cool SL Viewer v1.19.0.5 release 14 and v1.20.10.0 release 2 are available for Linux on http://sldev.free.fr/

They both implement RestrainedLife v1.11, with the crash bug fixed.

Enjoy !

Hi Innula, look under Advanced > Rendering

The last 2 options in that menu
Attached Lights
Attached Particles

And I can't help on the HUD/snapshot thing... it works as expected here.

LL just released a new RC download, try that and see if it also has that problem

So far I have been pleased with the performance of 1.20... a few freeze ups that I just found out might be related to using the "Run Multiple Threads" option.

The only "problem" is I think I like the default 1.20 friends/groups window a bit better. When shrunk to it's smallest size it's wider, and shorter and is less intrusive when you have a wide screen. But the coolviewer buttons bar is much better, so it's a toss up.

Thanks, all.. The problem seems to be associated with a particular item, my Ring of Total Submission by Mo Noel. When that's unlocked, everything behaves as expected (as does everything with either a locked Amethyst or Dari collar. I've dropped Mo a note asking her to investigate the matter.

The whole point of the 1.18.0-ish friends and groups list is precisely to get more friends/groups displayed for a less intrusive floater: for lists, it is way more logical to use floaters which are as tall as possible and as narrow as possible. The Cool SL Viewer allows you to do just that, while with the introduction of the voice viewers, the stupid communicate window layout resulted in wide friends and groups lists (the buttons being set beside the list instead of under it) where you can only see a few entries at once or have no other choice than to enlarge the floater vertically, resulting in a very big and intrusive floater.
In my viewer, I expanded my Groups list floater tall enough that I can see all my 25 groups at once, and yet it only eats up 1/6 of the width of my screen (1280x1024), thanks to the vertical layout (with the buttons at the bottom of the floater). Same with the friends list: I can see with a single glance and without any need to scroll the list who is online and who is not, something you can't do with the horizontal layout of v1.18.1 and later viewers.
With the use of wider screens (1680x1050, for example), you will even want more vertical floaters, as you got plenty of room to stack them horizontally.

It's great to see a Cool SL viewer for the 1.20 series, but I'm a bit perplexed by the 1.20.10.0 version number - does it include LL-supplied patches that came after the 1.20 RC9 release today?

Given LL fails to publish the sources for the RCs in a timely manner (and when they do, most often the sources do not even truly correspond to the published binaries !), I have no other choice but to use the SVN sources. The latest SVN sources are branded as v1.20.10.0... and you are not the only one being perplexed with LL's numbering.... They used to increment the last (nano) digit with each release (i.e. we should be at v1.20.0.10), and now (starting with v1.20) they are incrementing the micro... Go figure !

In any case, the v1.20.10.0 sources do include the very latest fixes by LL... of course with the risk that some of the fixes over v1.20.9 could introduce new bugs not seen in the latter... But like I wrote already, the Cool SL Viewer v1.20 is an experimental viewer, so...

I've now had a lengthy discussion with Mo Noel, who has been her usual helpful self, and we have established what's causing the phenomenon. It's because, unlike my collars, I have her ring locked in undetachable mode, which I hadn't realised.

It is apparently a feature (as in, "not a bug but...", in my opinion) of the latest RLV that if you have anything thus locked, your hud attachments show up in photos even though you can remove your AO or Mystitool manually.. the idea was, apparently, to prevent people wearing locked blindfold huds cheating by taking pictures. Marine apparently tried making hud attachments show up in pictures only when one of them is locked, but couldn't, so now, if you have anything locked undetatchably, your AO shows up in pictures, at least if you are using the latest RLV it does.

I must confess I had thought that having my Amethyst or Dari collar locked meant I couldn't take it off while using the RLV, but I was wrong. I just have done.

Anyway, the workrounds for me seem to be either to ask my Master to lock my ring in "classic" mode (which mean that, like my locked collar, it will come off but complain to him about it) or to revert to an earlier version of the RLV.

i dont do jira, i want my solutions within my lifespan...

patch follows:

--- secondlife
+++ secondlife 2008-06-06 12:06:15.993472413 +0200
@@ -109,8 +109,14 @@

export SL_ENV='LD_LIBRARY_PATH="`pwd`"/lib:"`pwd`"/app_settings/mozilla-runtime-linux-i686:"${LD_LIBRARY_PATH}"'
export SL_CMD='$LL_WRAPPER bin/do-not-directly-run-secondlife-bin'
-export SL_OPT="`cat gridargs.dat` $@"
+cp gridargs.dat /tmp/gridargs.dat
+for i in $(cat /tmp/gridargs.dat|awk '{print $1}'); do
+ echo $@ | grep -- "$i" && grep -v -- "$i" /tmp/gridargs.dat > /tmp/gridargs.dat2 ;
+ [ -f /tmp/gridargs.dat2 ] && mv /tmp/gridargs.dat2 /tmp/gridargs.dat;
+done

+export SL_OPT="`cat /tmp/gridargs.dat` $@"
+
# Run the program
eval ${SL_ENV} ${SL_CMD} ${SL_OPT} || LL_RUN_ERR=runerr

i dont do jira, i want my solutions within my lifespan...

patch follows:

--- secondlife
+++ secondlife 2008-06-06 12:06:15.993472413 +0200
@@ -109,8 +109,14 @@

export SL_ENV='LD_LIBRARY_PATH="`pwd`"/lib:"`pwd`"/app_settings/mozilla-runtime-linux-i686:"${LD_LIBRARY_PATH}"'
export SL_CMD='$LL_WRAPPER bin/do-not-directly-run-secondlife-bin'
-export SL_OPT="`cat gridargs.dat` $@"
+cp gridargs.dat /tmp/gridargs.dat
+for i in $(cat /tmp/gridargs.dat|awk '{print $1}'); do
+ echo $@ | grep -- "$i" && grep -v -- "$i" /tmp/gridargs.dat > /tmp/gridargs.dat2 ;
+ [ -f /tmp/gridargs.dat2 ] && mv /tmp/gridargs.dat2 /tmp/gridargs.dat;
+done

+export SL_OPT="`cat /tmp/gridargs.dat` $@"
+
# Run the program
eval ${SL_ENV} ${SL_CMD} ${SL_OPT} || LL_RUN_ERR=runerr

The Cool SL Viewer v1.19.0.5 release 15 and v1.20.10.0 release 3 are available for download.

They both have the missing location tracking arrow bug corrected. v1.20 also got more UI skin reversal (in the search tabs) and now displays again properly the SL login screen.

Enjoy !

The Cool SL Viewer v1.19.0.5 release 16 and v1.20.11.0 release 1 are available for download.

They both have a fix for a RestrainedLife bug (non-blockable group IMs), and v1.20.11.0 uses the latest SVN sources from LL.

Enjoy !

That old discussion about the Cool viewer crashing at start (with a floating point exception) isn't CPU dependant at all. I finally got the possibility to get new hardware today and as Linux systems thankfully (in most cases) are very hardware portable I just moved all the system onto the new machine.

However the same problems persists! How about that one?
(And just to be 100% clear, it is not a single piece of hardware moved from the old system)

Down to the facts then:
Cool viewer 1.9.0.5 diff 16, taken from another machine where it works perfectly.
Running on a DualCore where the LL one makes a nice 30 FPS easily.
OS is Debian 4.0 (the stable release).

My guess is that some library is unhappy (yes yes, I know Debian doesn't use the latest exactly), but where to start looking?

(Haven't tried the RC/1.20 version yet... )

Did you try compiling yourself, deleting the ~/.secondlife directory before running, or both yet ?

Haven't tried compiling it yet, but deleting the ~/.secondlife directory doesn't help.
It seems that it is something that happens when the cool patch is applied, as the normal corresponding LL viewer works before the diff is applied.

30 fps only on a DualCore machine with a new video card ?.... Ugh !!! That's really a very low figure... I get 25fps on average with my old Athlon XP 3200+ and NVIDIA 7600GT, and I get over 80fps in my skybox with v1.19.0.5 (note that by upgrading from v2.6.23 kernel to v2.6.25 one, I got a very high gain in fps, as both v1.19.0.5 and v1.20.11.0 show a 15% fps rate increase on my system ! Linux is definitely getting faster with each new kernel version :-) ).

I would expect a 40fps on average on dual core systems with modern video card (NVIDIA 8xxx or equivalent).

Which leads me to a question: are you sure that your kernel was not compiled _without_ FPU support (or with FPU emulation support) ???

If I were you, I would start by reinstalling a newer distro on an other partition and see how things go there.

In any case, none of the patches in the Cool SL Viewer change anything about how the FPU is used: only the compilation changes from LL's builds (more optimizations, gcc 4.1 instead of 3.4, different libraries though the critical ones are LL's and used from the viewer's lib/ directory at runtime). So, the ultimate test would indeed be to compile the Cool SL Viewer yourself.

Henri.

PS : as a side note, the Cool SL Viewer releases are compiled on a Mandriva 2007.1 system and tested also under an Ubuntu Fiesty system (which is Debian-based).

Didn't want to brag, so that's the average from a reasonably frame-needy place with lots of moving textures, prims and other things that need constant rendering. (Well maybe not the best technical term but probably understandable?)



Ah! Well this distro have 2.6.18 so that's a bit behind. Something to look forward to then



Very good question. I haven't a clue actually *blushes* That could indeed be an issue then.



I will do that a bit later on when i have some spare time. I have another machine that i could use for that, which behaves exactly the same (P4 with 7600GT in, so it's somewhat similar...)



I know, I know... I'm not that tech savvy that I love to compile things like this, but it would be interesting to try indeed.

Anyway thanks for some interesting thoughts, I'll update if I can put the finger on something later on. Keep up the excelent work of yours meanwhile!

Hmm.. I have suddenly started getting the following message when I attempt to log in, using Second Life 1.20.11 (0) Jun 11 2008 21:21:23 (Cool SL Viewer) RestrainedLife viewer v1.11d: "Viewer Update Required: This version of the Second Life Viewer is out of date. In order to connect, you'll need to download the required update containing the latest fixes and features"

I ignore it and connect as normal..should I be worried that soon I won't be able to? I seem to recall a few months ago some compulsory update banjaxed the Cool Viewer for a bit because SL couldn't recognise it as an up-to-date version even though it was.

This message is irrelevant to the Cool SL Viewer and you can ignore it safely.

LL simply changed the way the welcome screen is displayed, and in v1.20 viewers they now send the channel and version number from the viewer to the CGI script, which in turn generates the HTML code for the page.
Alas, when the channel is not "Second Life something" (something = Release, Release Candidate, Beta or Firstlook), they don't return the normal SL welcome screen but point on an alternative one. To fool the CGI script, I removed the info about the channel and version in the Cool SL Viewer v1.20.11.0, and it did work for a bit (i.e. it is like if you connected with a v1.19 or former viewer).
But LL changed the CGI script again, and now, failing to send the channel and version results in the "outdated" box to be displayed on the welcome screen... I guess I will have to spoof it and make it believe it's a release viewer.

Note that the welcome screen, is completely independent from the login URL, in which the Cool SL Viewer does identify itself as such and with its true version number: so far, LL never blocked viewers with non-official channels, even if their version would be considered deprecated for an official viewer channel.

Henri.

Will it matter much, as far as speed goes, if the viewer is compiled with SSE or SEE2?

Also, how come my comp can run 1.19 and get an barely-passable frame rate of six to fifteen frames a second, but the 1.20 viewers, I only get about three?

My processor is a VIA C7-D @ 1.5GHz, and my graphics card is an ATI Radeon X1300.
I am running Arch Linux.

No, the gain is marginal (less than 5% in frame rate in most cases). The reason is simple: there is almost no SSE optimization in the viewer source code itself, and the compiler alone can only do by itself simple SSE optimizations on floating point arithmetic and such.


It is not surprising at all. Even with all shaders off, the Windlight renderer on which v1.19.1 and v1.20 are based is much slower than the "classic" (v1.19.0 and before) renderer on "old" computers (read: computers with single core processors).


Note that the VIA processors are hardly a match to the SL viewer hardware requirements, and any single core processor below 2Ghz (AMD) or 2.5GHz (Intel) gives poor results anyway.

For "old computers", the performance bottleneck is obviously the processor itself and even with a high end graphic card, you can hardly squeeze more than 25fps out of them in average, which means down to 5fps or such in render challenging areas (a dance club with lots of avatars, animated textures and particles emitters, for example).

And yet two new releases of the Cool SL Viewer: v1.19.0.5 release 17 (with RestrainedLife v1.11e) and v1.20.11.0 release 2 (with RestrainedLife v1.11e and a bug fix in how the media remote control panel is displayed).

Enjoy !

Whenever I try to upload anything, the file picker dialog comes up for a second, then the viewer crashes. It does this on the original viewers, too. I Googleed around for it, and found this -- jira.secondlife.com/browse/VWR-5144 . I dunno if Torly's saying in that last post that it's been fixed in 1.20, or not.

Is there any way to fix this aside from having to upgrade to the RC, since my comp can't handle that well at all?

No, the issue was closed (together with many others) with the pretext that it should not have been reported as affecting the Windlight version (and that it could therefore _supposedly_ have been fixed in v1.19.1.4 since). But there is no fix to this issue, obviously. Did you try with the RC to see if it did fix this issue for you (even if your computer can't "handle it well", you should be able to use it for a few minutes in order to verify the problem) ?
If the issue is still present in the RC (or in LL's v1.19.1.4, as it is still the official release viewer for now), you should reopen the issue on the JIRA. I don't have XFCE here and can't therefore test it myself (I see no problem whatsoever under GNOME).