Cool VL Viewer forum

I am new here and pretty confused about the technical details. I have been using the Cool VL Viewer for a while as it does seem to be the gentlest on my poor old machine. (I joke that the machine is sooo old that the memory is in trilobites !) I get all sorts of messages "do you really want to do this" and often frame rates of one every 2-4 seconds, that tops out at almost 8 FPS in a totally empty sim. Obviously I don't run about much (love the double click to teleport when keeping up with others) but I have a fair skill with Blender and mostly build rather than run about.

I have a Toshiba Laptop with the video on the motherboard so upgrades are not available, and the RL money situation means that there will be no replacement anytime soon. I do have a big CRT (from the dead real computer) that I kick out to so can run dual screen, and there lies the first point of request . With the screen all cluttered with windows it is very hard to see much, and it would be really neat to be able to toss them up to the CRT (a' la GIMP) and keep the Viewer for viewing (I have no idea how hard or easy that is, but I know a lot of folks are running dual <or more> screen, and I don't know why more programs don't follow Gimp's lead)

The other is a more personal need as most of what I do is sculpties and copy paste does not address sculpties (firestorm does but has many other issues, including more lags and crashes). Particularly in SL I have all sorts of stuff made with the old megas, that report the mega creator as the creator, so much of what I built there cannot be taken to the Open Sim grids where I mostly spend my time and copy pasting and replacing seems the only solution, as most sizes can now be used without megas.

I know that your efforts are a labor of love and I really appreciate it as I would hardly be able to be on grid at all except for those efforts. Thank You.

Well, please, for a start, don't post a message unrelated with a given topic in the said topic... Your post got no relation whatsoever with the development roadmap, thus why I had to split it into its own topic.

The Cool VL Viewer has been highly optimized by me, CPU code-wise. It means, that when displaying a frame, when compared to other viewers and all things equal settings-wise, it executes less CPU instructions which, depending where the performance bottleneck is in your system can lead to either higher frame rates (if your CPU/RAM is the bottleneck) or lower CPU load for the same frame rate (if your GPU is the bottleneck).
The Cool VL Viewer also got a memory usage tracking and adaptive algorithm which makes it the stablest 32 bits viewer around (simply because other viewers never check whether a memory allocation has failed and lamentably crash when they use the returned NULL pointer like if the allocation had been successful; they also don't try as hard as the Cool VL Viewer to auto-adapt their textures and objects caching so to keep the allocated data within the memory limits).
Finally, the Cool VL Viewer runs (because of the build systems it is built on, that are using older libraries than other viewers) on older OSes (Windows XP SP3, Linux with glibc v2.11, MacOS-X v10.6).

The three above characteristics are what caused it to be considered the "best viewer for old computers" by many users.

However, the Cool VL Viewer has still been updated over time to be kept on par with LL's latest viewer, meaning the current versions are about just as demanding as LL's current viewer (or any TPV based on it). In particular, the shaders are the same as LL's viewer (together with some added fixes).

In conclusion, while the Cool VL Viewer may run a tad bit better than other viewers on old systems, it still can't magically turn your prehistoric computer into a modern, top-performing machine !

You cannot use a dual screen setting unless you graphics card, graphics drivers and window manager allow it. This is not something under viewers or Gimp developers' control...

I don't see the point in copy/paste for sculpties... Just SHIFT-drag the sculpty in-word, and it will get copied (if you have copy permissions, of course !). You may as well "Import/Export objects" (see the Files menu and the pie menu for objects) as long as you are the creator for them: this also can be used to export/import sculpties.

While I don't know how they implemented it in Firestorm, copying a sculpted prim means actually copying a texture onto a new prim, texture that may or may not be copy-ok/transfer-ok for you... It would be against LL's TPV Policy (TPVP) to allow such a thing to happen unless you are the very *creator* of the sculpt texture. Equally, LL's TPVP doesn't allow any viewer to export/copy assets that the user is not the creator for (this includes library textures, mega-prims, etc). The Export/Import feature of the Cool VL Viewer does check that you got all the necessary permissions (including a texture asset in your inventory, created by you, and holding the UUID of the texture you are trying to export), which is not the case of the Edit floater Copy/Paste feature. I don't intend to change this.

When I copy a texture in most viewers it co[pies the texture name, color, transparency, bump map settings, planar/default etc (assuming privilege to do so is enabled) and all those settings are applied to the prim where you paste it. This is very useful, and I see Cool VL Viewer does not do that either. A typical case is a build with many linked columns and I want an updated sculpty map, and customized new texture map in each of them. They are all carefully sized and placed, and all I want to do is the update shape. in FS and in sub element mode I do one and copy, then pick all the rest and hit paste, and now they are all the new Sculpty map and Texture. If either the Sculpty map or Texture is not in your inventory the FS copypaste stuff does not work (though the other settings of mapping, mirror, etc do paste.) Since mesh has no such parameters i have to launch the new version and copy and paste everything, as I remove and unlink the old version, while linking in the new, if there are many instances this can be very tedious.If either of these is what I need to do I am pretty much forced into FS with all the other downsides to it.


As for the child windows issue, I believe it is a setting in the windows design itself that all the child windows stay inside the original or are allowed to be outside of it, such as is the case in Gimp. As I mentioned my expertise is thin in those areas and I am operating out of rumor and the facts on the ground like Gimp that it is possible. For now every viewer I know of has the child windows stuck in the main window, so seeing what is actually going on continues to be a challenge if you are also building, texting with others, and needing the inventory and whatever huds are built into the Avatar.

Another common circumstance I have- I have a sculpty tree that is copy mod only that is a signboard tree that is a sculpty of a single tree, The prim is copy mod so I can change it but own neither the image texture or sculpty texture. I have no use for a sculpty of a single tree but have made many of my own of 16 trees to a prim in many different configurations. I like the texture, and so copy paste one of the many configurations, and voila an instant forest of that tree texture that I cannot copy, However that particular configuration is not ideal so I look about the forest for one that is better and copy paste it instead. I have not violated any TOS, and cannot much less will not sell that to anyone else. This is another instance where being able to copy the sculpty parameters is very useful. Of course all the processes could be done one thing at a time, just as was the case before anyone thought to add copy paste to the viewer, but if one thing is good then everything is better (as long as it is controlled).

You do not need a copy/paste feature for such a case: simply select (Editing it) the model, then SHIFT-move it (using the "Position" tool of the Edit floater): it will immediately be duplicated (provided you got the right permissions, which are determined server-side and is therefore not in the viewer's control). Then select the two copies, and SHIFT-move them again, and with just two moves you got 4 copies... another SHIFT-move and you get 12 (or you can select the 8 copies and SHIFT-move them all to get 16), etc... All you have to do once you got the number you wanted is to customize (by replacing a texture or changing a shape) the copies you wish to modify (just like you would have done after a copy/paste session). It's in fact even faster than using tedious copy/paste features in multiple tabs on multiple prims you create one by one !

Yes, you DO violate the TOS, and the TPV you are using *IS* violating the TPV Policy if it allows to set a texture UUID for which you don't have a corresponding inventory asset *that you created/uploaded yourself* !!! Please read paragraphs 2.a and 2.b of the TPVP !!!

By allowing you to copy a texture you did not upload yourself from a mod-ok/copy-ok (and even mod-ok/copy-ok/tfr-ok, i.e. "full perm") object to a prim you create yourself (and that you may therefore copy and transfer to others), a viewer actually permits you steal contents by circumventing the SL permission system (paragraph 2.a violation) and by providing a feature that the official SL viewer does not allow (paragraph 2.b violation). After you copied the texture on your self-created objects, nothing would prevent you to resell the latter either, like if you were its original creator (the textures don't have permissions on themselves: only the assets bearing the texture UUID got permissions, in your inventory only. This is unlike prims which bear appropriate permissions both in the inventory and once "rezzed" in-world).

If some TPV developers have not fully understood the consequences of some of their coding, I will, on my side, *never* implement a feature that violates the TPVP. Period.

There is no "child window" at all in the viewers: there are only "floaters". In all existing graphical viewers, the *full* UI is drawn in OpenGL inside the viewer window, and you therefore cannot move a floater outside the latter !

While it would be possible to design a viewer with individual sub-windows, it would require a total rewrite of the existing viewer code, it won't allow many things that floaters and panels allow to perform (such as the media controls panel on media-bearing prims), and the UI would have to be coded in an OS-dependent way: you don't deal with windows in the same way under Linux (under which you'd have to choose between GTK+, Qt, FLTK, etc... there are many options, each suitable for a given desktop environment), MacOS-X or Windows: they all got a different GUI and totally different coding conventions (API) for them.

In summary: it's not going to happen any time soon...

A long time ago in SL history, there was a client that could separate the floaters from the mainscreen and it was offered to LL but they rejected the idea as leading to a complication of the viewer that they didn't want to spend time on. The following are the informations on that:
http://icyspherical.blogspot.com/2010/0 ... globe.html
https://lists.secondlife.com/pipermail/ ... 71743.html
and the name of the viewer was called MonoVida Studio/MonoVida Communicator/OpenSim Communicator...and later just called Iceshpere Viewer...all designed by Jonathan Ballard aka Dzonatas Sol...but I have had some discussion with this creator and he seems no longer interested in SL.