Henri Beauchamp

I don't see it ”canned” any time soon (and never in my viewer !)... You are probably confusing the possibility to disable ”basic shaders” (now removed from the EE renderer), but those would only affect pre-v2.1 OpenGL, and the WL renderer already could not render things correctly with basic shaders off. As for deferred rendering (AKA ALM), I personally dislike it a lot and pretty much never use it myself: it makes everything look blurry and gloomy while non-deferred rendering is crisp and vibrant. Not to mention a lowered FPS rate in ALM, which becomes even more critical with the EE renderer...

Irrelevant quote... The only rule there is not to break shared contents for *others* (e.g. via things the viewer would transmit to the servers and that other viewers won't be able to render), not for changing how things look for yourself. 😝 In any case, your (I'm afraid, dictatorial) demand has already been rejected by LL, by design, since they always allowed custom environments, viewer side, be it with WL or EE... End of discussion for me.

You can make up any rule, but you cannot impose what a user displays on their computer screen... It's called freedom. Sorry. Is that a menace ? 🤣

It could easily have been added to the Windlight renderer/shaders at a much lower cost in frame rates (with 30-50% loss in EE when compared to WL).... Thing is, it was already possible with WL... And the syncing with each user's RL is not even what truly matters for many SL users, namely role-players: the rhythm of a role-play (especially between para-RPers) will never match or sync with any clock, be it the wall clock/ocal time (which is likely not even the same for each RPing partner), or the sim time (whatever its day length setting). ”Not home-made” programmer syndrome... Just because the feature existed in TPVs and not in LL's viewer, then you decide to break every ”standard” that LL did not define itself... Note that I am not advocating for one of ”my” standards here, since my viewer did not (natively) implement Firestorm's way of providing parcel customized environments (even if you could easily emulate it via Lua scripting in my viewer). I just find this approach (snagging TPV developers' work or ideas, and re-implementing or re-branding it as LL's without any request for comments or inputs from the original authors and, most important, from their user base), totally lame ! Sharing is a good motive... I suspect the ”selling” aspect was the main (and actual) motivation behind this feature... Not going to blame you for it since as a private company I do acknowledge that LL needs incomes... Especially to cover the total wastage of coding power and money that went into Sansar (RIP !). Too bad you pushed EEP to release status while it is was not even remotely ready for it ! I'm not opposed to progress and evolution (by far, as shows my early adoption of new features in my viewer), but I'm opposed to needless ”progress” that actually results in regressions. The huge loss in frame rates and the discrepancies in how things are rendered in EE viewer compared with WL will just make more people grumble, complain, or resist to the bitter end to that change.

I'm very sorry to contradict you on that point, but I deny you (or anyone else) the right to control how environment is rendered on *my* monitor. You might find it cool to *impose* *your* view on others, but I don't find it cool *at all* that this could ruin *my* fun, *my* way to (and rhythm in) RP, or simply to make things not visible on my screen because you love super-dark environments while I try to preserve my (aging) eyes by keeping the luminosity (relatively to the room ambient light) as low as possible on my screen. The Cool VL Viewer, for one, will *always* provide the final user with full control on what they see on their screen (which includes opting for the Windlight renderer if they think 50% more frame rate matters more than ”prettiness” of the sky).

You mention 2006, which happens to be the year when I joined SL. So, let me tell you that it seems that your memory is rather imperfect, or perhaps ”selective”, because back then, there were day-long grid down-times (pretty much every week, and not always planned ones, by far), something yet to be seen nowadays. Your affirmation cannot be wronger actually, and LL does fix a lot of things. Beside the servers, the viewer also saw a tremendous improvement in its stability (back in 2006, staying logged in without crashing for a full hour was deemed a record breaking performance). I'm the first to criticize LL when they do things wrongly (and they sadly regularly do things wrong, such as pushing EEP to release status before it is even remotely ready), but they cannot be criticized on this particular point.

And of course, you could try the Cool VL Viewer v1.27.0 which got both Windlight and Enhanced/Extended Environment support and the two corresponding renderers. It is also unaffected by the ruined parcel/region environment, even when using the Windlight renderer, because it uses the EE parcel settings and translates them into WL ones to render them...

I'm older !... MUDs, MUCKs, MUSHes, MUXes, existed waaaaay before SL emerged as a vague concept in Philip Rosedale's mind (I suspect he got inspired by Furcadia)... I started RPing online on FurryMUCK, back in the early 90's...

:just smirks... Note the ”:” instead of ”/me ” (i.e. easier/faster MU*-like emoting), which was my very first patch to the Linden code base, back in the ”Cool SL Viewer” days... The whole spirit of my viewer is behind this very first patch (that every TPV adopted since): faster, easier, lighter... and still full-featured. 😜

This already happened with the Cool VL Viewer v1.27.0 (just like I more or less announced in this forum months ago), and yes, Extended/Enhanced Environment rendering will stay totally optional in the Cool VL Viewer future releases. I am currently working on making the EE renderer compatible with Windlight settings (the other way around, i.e. using (a subset of) EE settings with the Windlight renderer, already worked for months in the Cool VL Viewer). Once this will be done, v1.27.0 (experimental branch) will be promoted as v1.28.0 (stable branch).

This got nothing to do with multi-monitor support (neither with threading, as mentioned in replies), but with how the viewer UI is implemented. Indeed, the first time I launched a SL viewer (back in 2006), I have been extremely surprised to see that the UI (menus, floaters, panels, etc) was all rendered in OpenGL, which is a rather costly way of dealing with an UI, when GTK+, Qt (for Linux) or native OS UI elements (for Windows and macOS) could be used instead (at zero cost in term of frame rate)... Back at that time, the CPUs were mono-core ones (with barely a quarter of the power of one of today's CPUs single core), the GPUs were 1000 times slower/less powerful than today's GPUs and the OpenGL UI consequently did represent quite a significant fraction of a 3D frame rendering time. While that choice (rendering everything in OpenGL, UI included) could be seen as very disputable back in that time (mainly because of performance concerns), it did yet bring a number of advantages: It is fully cross-platform, providing the user with an uniform experience in all three OSes the viewer could be run under. It is easier to maintain for viewer developers (no need to deal with each OS UI peculiarities, or even with several UI toolkits for the same OS such as GTK+ and Qt under Linux). It allows for a tighter bind between the viewer code and the UI (easier to keep UI elements in sync with what happens in-world). It inherently provides a non-blocking UI (since the UI is refreshed in the main loop, not blocking the latter waiting for the reply of an external UI toolkit itself dependent on the user actions), and this without the need to use threads. It also must be noted that it is how most games are coded anyway... One of the drawbacks (beside the frame rate performance impact) is that you cannot drag an UI element out of the 3D rendering window. It is doable (it would require heavily modifying the llui viewer library to use a toolkit such as Qt or wxGTK), but not an easy task either and would be quite time consuming...

You can try the Cool VL Viewer v1.27.0 (experimental version/branch), which implements a dual renderer (Windlight and EE, switchable on the flight), beyond also providing EE settings to Windlight real-time translation (which also works and has been working for months in the v1.26 stable version), when using the Windlight renderer...

Make sure your mesh body is set for alpha blending or alpha masking, else Alpha won't work with baked textures on mesh.

Yes, I already spotted this, but convertToLegacy() calls convertAtmosphericsToLegacy() and there, is a comment saying: And the whole conversion depends on the actual presence of SETTING_LEGACY_HAZE key in the EEP settings LLSD... Should I conclude that this key is indeed (and will stay, in the future) present in the EEP settings ? It should not be hard to add configurable textures for Windlight's Moon, Clouds and Sun... The independent Moon position would just be a missing feature.

The idea is precisely to implement the same conversion algorithm into viewers capable of dealing with EEP settings (at both the inventory/asset and LLEnvironment levels) but that won't adopt the EEP renderer (instead keeping Windlight's renderer). The Cool VL Viewer v1.26.23 (i.e. the experimental branch) is one such viewer (you can even edit the EEP settings in it, apply them to the region, etc, but of course, you cannot see EEP settings applied locally rendered as their equivalent Windlight ones). I could code such a feature myself, but why reinventing the wheel ?... As I explained in a previous post, I am for now undecided about what I will do regarding EEP (and more precisely its renderer): I could adopt it (if it improves enough to avoid loosing FPS when compared to the old Windlight renderer), or implement Windlight rendering of EEP settings (via this conversion algorithm, for non-region/parcel settings)...

Would LL be so kind as to publish the relevant code, so that it could be integrated without having to reinvent the wheel into viewers that keep the Windlight renderer (this way, the viewers that support EEP settings but don't use the EEP renderer could render Windlight settings corresponding to EEP ones, even when the EEP settings do not come from the region itself) ?

This is not how things work: for a start, your ”flag” cannot be transmitted together with the avatar bakes. The new UUID set will be ”transparent” to the final users: it's the code behind the UI of the texture picker that will take care to pick the ”*_NO_HIDE” version of the UUID constants when the ”Auto hide body part” check box is un-checked. It will also be fully backward compatible with the current BoM implementation. Frankly, this is so trivial (it can be implemented and fully tested in a mere couple of hours, at the very worst), that it would be a shame to wait months and an hypothetical ”follow-on project” to have it... I bet you will see more and more reports about ”BoM is broken because I can't have my feet/hands/head/whatever shown while using a bake texture on the rest of the mesh body part”... As for the JIRA, I gave up using it, sorry. It does not even remember the login credentials over sessions (even with the ”Remember login” check box checked), and most things I reported on it over the many years I contributed to the SL viewer development and debugging got mostly ignored... This is without mentioning that (long time: 12 years already) viewer developers such as myself cannot even see or contribute to most of the JIRA issues (apart from the BUG ones, provided you are the initiator)... :-/

Yes, this is typically a case that would be fixed by my suggested NO_HIDE set of bake UUIDs...

I can speak only for myself and the Cool VL Viewer, but while I already backported the environment settings editing/importing/creating stuff (UI (fully reworked), inventory, etc) in the experimental branch of my viewer (v1.26.23), I for now refrained from backporting the rendering part. Why ? Because it is obviously a moving target with lots of breakages still to be repaired, and with abyssal performances. At this point, I am not even sure I will actually adopt EEP rendering for my viewer, the reasons being: This is not something I need. To tell you the truth, I don't even use ALM (it looks too blurry and gloomy for my taste) and I keep my viewer locked in ”midday” with default Windlight settings (because well, I don't care much about the photo-realistic aspect of SL: for me SL is just a platform to role-play, and imagination is the key factor in RPs, not things that would be imposed on me such as the day length, that obviously cannot follow/match the variable rhythm of a RP). If it means that I must give-up performances for a feature I never asked for and that I cannot disable to regain the original performances, then screw it ! For now, I am considering three options: Not implementing EEP rendering at all, but making it so that EEP settings are ”translated” and rendered as their Windlight counterparts. Keeping the Windlight renderer and implementing the EEP one along it, allowing to switch back and forth between them (thus letting the final user the choice between ”prettiness” and performances). Waiting (weeks, months, who knows ?) after EEP makes it to LL's viewer and see what happens (will performances increase over time to match the Windlight renderer's ?). Now, I think that things could be improved a lot, performances-wise, if you could consider the following suggestions of mine: Do we really need to recalculate the environment parameters at *every frame* ?... 5 updates a second sounds like more than sufficient to me (this could even be made user-configurable, because to tell you the truth, one update per minute would be acceptable for my use of SL), and cached parameters could be used for all the other frames in between two updates. Won't it be smarter to delegate environment calculations to a separate thread ?... Once the above caching implemented, it would be trivial to sync the results once per frame between the environment calculation thread and the viewer rendering (and main) thread. With today's multi/many cores CPU, we do need to use more threads !!! These were my two cents about EEP...

PsiCorp Core v2 avatars can also be setup to use BoM textures and work great with them. Core Nova can too, but alas its UV maps are not so great (especially on the back side: the buttocks UV map is totally off SL's avatar, and there are also issues around the neck and shoulders).

@Vir Linden There is a feature I already wrote about on this forum (it was last year, in the initial thread about BoM), that I still think would be useful: have an additional set of bake UUIDs that won't trigger the auto-hiding of the corresponding parts of the avatar. I encountered no later than yesterday a use case for such bakes: a mesh body avatar (that lets you use the SL avatar head) with a half-neck mesh part, that allows a smooth blending of the mesh and SL avatar head/neck: when applying the baked head texture to the neck (so that the neck part of the mesh is colored like your SL avatar neck), the head vanishes... You can't use a bake on the neck, meaning that particular mesh body cannot blend properly at the neck level... Other use cases would be mesh bodies with parts of the underlying avatar showing (think cyborg, amputated avatars, etc): for those you don't want the full upper or lower body to vanish when using baked textures on the mesh parts, but instead would use appropriate Alpha layer(s)... The implementation would be trivial, as I see it; in the texture picker, add a ”auto-hide body part” check box (and IIRC that check box existed in the initial BoM implementation, but was not ”wired” to any code in the viewer), and when not checked, instead of applying, say, ”IMG_USE_BAKE_HEAD”, the texture picker would apply a new ”IMG_USE_BAKE_HEAD_NO_HIDE” UUID to the edited face. Then, in the viewer code, skip the body part auto-hiding when any of the ”*_NO_HIDE” bake textures are used instead of their counterparts.

The Cool VL Viewer already supports bake on mesh (and has been supporting it for over a year already), and the current sources for the viewer can as well be compiled with the new Universal tattoo layer support. The next release (to be published on next Saturday) will have the universal layer support compiled in.

AFAIK, the Cool VL Viewer is the only viewer to still be able to render ”classic clouds” in SL, for I added local (viewer-side) cloud data generation shortly before LL shut it down on their server (I basically reverse-engineered their cloud data generator, and when the said data is not sent by the server, the viewer uses its own data generator and injects the result in the renderer): the only difference with server-generated data is that every Cool VL Viewer user in the same sim gets a different cloud coverage (since the data is not shared between them all). Also, classic clouds are generated for *all* *rezzed* sims (i.e. if you increase draw distance enough to see them, you will have them rendered in the neighbouring sims as well). You may also change the classic clouds rendering altitude (it defaults to its normal 192m average altitude). Singularity, on its side, is able to render classic clouds when the server sends the corresponding data (i.e. OpenSim non-var-region sims).

Raycasting against rigged meshes *does* occur and is fully implemented in the viewer. It is just not taken into account for touch events, drag and drop, etc... Again, the rationale was probably that since rigged meshes were destined to replace the SL avatar mesh body parts, they were to be considered as the latter and not as a ”normal” attachment...

This is not a bug, but a feature... LL intentionally coded touch (left mouse button click) in the viewer to ignore rigged meshes. This is not because it could not be done (it could !), but my guess (since no comment in their code explains it) is that the rationale behind it was that rigged meshes are supposed to ”replace” the SL body mesh, and the latter is not clickable either ! Allowing to touch your rigged mesh body would, for example, prevent you from stirring your avatar with the mouse (by touching its body an keeping the left mouse button pressed while you move the mouse to stir). You may however right click rigged meshes and choose ”Touch” in the pie menu to get the desired effect... On the condition that you did enable ”Pick rigged mesh” in the Tools menu of the viewer.