[Environmental Enhancement Project (aka EEP!) Feedback Thread]

9 minutes ago, Kyrah Abattoir said:

If you don't want me to control how environment is rendered on your monitor, or to be imposed specific views. Why would you even set foot on my land?

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

Quote

Ald I'll be sure to bring that up in a TPV meeting.

Is that a menace ? 🤣

[Environmental Enhancement Project (aka EEP!) Feedback Thread]

On 7/9/2020 at 6:57 PM, Oz Linden said:

Because we wanted to provide you with:

• A bunch of new environment parameters and capabilities (custom moons, etc)

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)....

Quote

• Support for customizable day lengths and offsets (sync your in-world environment to your real life)

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).

Quote

• Parcel specific and Experience-mediated environments (that work for everyone, not just those on particular viewers)

”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 !

Quote

• Sharing and selling environment settings as assets

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.

[Environmental Enhancement Project (aka EEP!) Feedback Thread]

On 7/10/2020 at 1:11 AM, Kyrah Abattoir said:

If only you didn't also add ways for users to bypass/ignore those new features and gave land owners/estate owner actual control over their (very expensive) virtual land.

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).

[What the hell is happening with Second life.]

48 minutes ago, Vicki Shim said:

welcome to SL where they take your money but still wont fix the issues since 2006 

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.

[EEP & Other SL Viewers]

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...

[Environmental Enhancement Project (aka EEP!) Feedback Thread]

6 minutes ago, Marianne Little said:

Second Life is my first and only ”game”... I'm old. I know nothing of other worlds.

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...

[Environmental Enhancement Project (aka EEP!) Feedback Thread]

4 hours ago, Marianne Little said:

/me takes another sip of coffee, and waits for Firestorm.

: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. 😜

[Environmental Enhancement Project (aka EEP!) Feedback Thread]

On 5/31/2020 at 2:22 PM, Chic Aeon said:

I was hoping from the beginning that someone would make EEP optional as you suggest -- mostly because so many folks testing it hated it LOL.   That could still happen maybe.   

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).

[Multiple Monitor Support]

On 6/7/2020 at 1:17 AM, Alec Kaestner said:

I'm talking about the ability to pop out, and move chat windows, notecards, HUDs, etc off to a second monitor, leaving a 'clean slate' for SL in all its SLishness :-).

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:

1. It is fully cross-platform, providing the user with an uniform experience in all three OSes the viewer could be run under.
2. 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).
3. 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).
4. 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.

Quote

Now, I'm not a programmer, but I wonder if some smart viewer programmer would be able and willing, to rise to the challenge, and garner a legion of fans (or at least, just me).

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...

[Environmental Enhancement Project (aka EEP!) Feedback Thread]

On 5/31/2020 at 11:34 AM, MarissaOrloff said:

Is there anyway to disable EEP and go back to the way it was? EEP has a huge impact on FPS.

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...

[Bakes on Mesh Feedback Thread]

8 hours ago, Cesartje said:

I cant get clothes alpha to work - i wear it, and nothing happens. It used to work fine. Help. 

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

[Environmental Enhancement Project (aka EEP!) Feedback Thread]

50 minutes ago, Rider Linden said:

The viewer's corresponding conversion code has been there for some time (It was put in place so that an EEP viewer could still update the environment on a Windlight simulator, and has never been removed, even after the whole grid switched.) 

You can find it in llsettingsvo.cpp. (found at the link).  Search the file for methods named convertToLegacy( ), there should be three of them.  The viewer conversions do not have the issue that impacted the simulator.

Yes, I already spotted this, but convertToLegacy() calls convertAtmosphericsToLegacy() and there, is a comment saying:

Quote

// These may need to be inferred from new settings' density profiles
// if the legacy settings values are not available.

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 ?

Quote

Be warned.  The legacy Windlight format does not include a number features such as customization for clouds and heavenly bodies, independent moon position, and several others.  These improvements are stripped in the conversion.

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.

[Environmental Enhancement Project (aka EEP!) Feedback Thread]

1 hour ago, Rider Linden said:

All simulators on the grid at this point maintain EEP settings internally and do a translation to the legacy windlight when a viewer requests the environment through the old cap.  It was this translation that was applying the improper scaling on our end.

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)...

[Environmental Enhancement Project (aka EEP!) Feedback Thread]

2 hours ago, Rider Linden said:

There was an issue on the servers that was scaling down the fog values when translating from the simulator EEP settings into legacy Windlight.

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) ?

[Bakes On Mesh - Releasing Soon!]

32 minutes ago, Ai Austin said:

More UUIDs and fallback textures would be a bit of overkill don't you think?  Better if it can be done to have a (one bit boolean) flag (default ”on” for compatibility) to let you turn off alpha hiding of the relevant part.

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.

 

1 hour ago, Vir Linden said:

Henri,

I think this is a good idea, and I've added it to our list of possible work for a Bakes on Mesh follow-on project.

We strongly encourage folks with these kinds of suggestions to file a JIRA about them;

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)... :-/

[Bakes On Mesh - Releasing Soon!]

46 minutes ago, LucyHerne said:

@Vir Linden I had an issue with my Slink body when BOM went live that meant I had to buy a set of Slink mesh hands. Before BOM I was using the Slink Mesh Body & Slink Feet but kept my System hands. With BOM I found my System hands were invisible because the BOM system was assuming the whole of my Upper Body was mesh. Is it possible the above suggestions from @Henri Beauchamp & @Ai Austin could be used to overcome this issue?

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

[Environmental Enhancement Project (aka EEP!) Feedback Thread]

On 8/12/2019 at 8:52 PM, Oz Linden said:

We're working as hard as possible to get the EEP viewer into shape to promote to default, after which we expect that it will be quickly available in most TPVs.

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:

1. 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).
2. 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:

1. Not implementing EEP rendering at all, but making it so that EEP settings are ”translated” and rendered as their Windlight counterparts.
2. 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).
3. 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:

1. 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.
2. 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...

[List of Creators Producing BoM-Compliant Goods]

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).

[Bakes On Mesh - Releasing Soon!]

@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.

[Bakes On Mesh - Releasing Soon!]

On 8/24/2019 at 4:39 AM, LittleMe Jewell said:

Now for the countdown to when the third party viewers release with it.

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.

[Would you play SL classic?]

On 7/14/2019 at 6:57 PM, DilliDallagio said:

Actually, there are two remaining V1-based viewers that still create those fabulous clouds. Singularity and Cool VL Viewer. And, as retro as they are, the are equally as retro for rendering those clouds only on the region you are in; they will not render them for the surrounding regions.

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).

[Touch detection for worn rigged mesh: what have I missed?]

On 5/11/2019 at 10:10 PM, Kyrah Abattoir said:

Option B: Rigged mesh transforms happen on the GPU end and click raycasts on the CPU, so they don't ”see” the same thing.

Option 😄 Raycasting against rigged objects might have been seen as too expensive.

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...

[Touch detection for worn rigged mesh: what have I missed?]

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.

[Bakes on Mesh Feedback Thread]

On 4/18/2018 at 9:26 PM, Vir Linden said:

Prevent baked textures on non-mesh attachments: I'm not sure if we would want that limitation. How about something like a rigid piece of armor, which might be defined in the same UV space as the system avatar, and where you might want to apply a texture derived from a clothing item? I'd be curious to hear if anyone plans to use bakes on non-rigged meshes.

I think you misunderstood me: I meant, non-mesh attachments (SL-prim based, and possibly sculpties) and I was not speaking about non-rigged mesh ones...

There is simply no possible way for a SL prim based attachment to bear an UV map matching the SL avatar's, so it makes using avatar bakes on them rather (totally, IMHO) pointless. The sculpties case could be advocated, but I personally doubt a sculpty could be designed which resulting mesh would natively map to any of the avatar's UV maps...

Also, I see no point in allowing to use avatar bakes on HUDs.

 

On 4/18/2018 at 9:26 PM, Vir Linden said:

Disabling auto-hiding, or more generally giving the user more control over what gets hidden, has also been discussed. No final plan on that yet.

I think it's a must-have: think of your armor example, that won't cover hands and neck, but that could use your baked upper avatar texture: you'd need a custom Alpha layer for it and won't want the upper avatar body to be auto-hidden. Plus, it's super easy to implement (simply doubling the pseudo texture UUIDs by adding a set for non-auto-hiding bakes).

[Bakes on Mesh Feedback Thread]

The Cool VL Viewer now supports "bake on mesh".

On a side note, this feature would be better named "avatar texture bakes on attachments" since it does not bake textures for any given mesh (i.e. meshes with UV coords not matching the SL default avatar won't show right) and allows to display baked avatar textures on any kind of attachments, including non-mesh ones and HUDs: this could possibly be of use for scuplties (if you can manage to build one that would map natively with Av UVs), but I fail to see any practical use for simple prims and HUDs...

Questions for the implementers:

• Will "bake on mesh" apply to "animesh" attachments ?
• Won't it be better to prevent bake textures on non mesh attachments (for speed optimization purpose and actual usefulness of the feature).
• Will there be some way to disable auto-hiding of avatar parts (I see a corresponding check box in the texture picker code, but it is currently not active and lacks any code for this kind of support). The idea is that you could wear, say, a rigged mesh calico which mesh won't cover the collar part around the neck neither the arms, and won't want the full upper body to get hidden as a result. Or, think of mesh "boobs" that could also use bake on mesh on SL avatars *if* it was possible *not* to hide the upper body part. As for how to implement it, the simplest way would probably be to affect a different pseudo-texture UUID for bakes without auto-hiding (e.g. IMG_USE_BAKED_UPPER_NO_HIDE in excess of IMG_USE_BAKED_UPPER).