Environmental Enhancement Project (aka EEP!) Feedback Thread

[Ehawee Ravenhurst]

This is the Firestorm jira entry where I added and what there was a reaction to:
https://jira.firestormviewer.org/browse/FIRE-23908#

[Chic Aeon]

5 minutes ago, Ehawee Ravenhurst said:

This is the Firestorm jira entry where I added and what there was a reaction to:
https://jira.firestormviewer.org/browse/FIRE-23908#

In case you didn't know this is apparently not a Firestorm issue (smile) but something that people have been complaining about for at least months if not years with EEP. Hence why I suspect the FS crew made this a beta and non-required version. Not sure if it will ever get fixed. But you did a great job reporting with the photos and documentation. Appreciated.

And very happy this wasn't forced on us Firestorm folks too.  

[Coby Foden]

30 minutes ago, Chic Aeon said:

Not sure if it will ever get fixed.

The excessive shininess in EEP has been fixed in LL's "Love Me Render" release candidate viewer:
https://releasenotes.secondlife.com/viewer/6.4.5.544028.html 

In that version the shininess looks pretty much the same as in non-EEP viewers.

[Kyrie Deka]

On 8/7/2020 at 8:09 AM, Whirly Fizzle said:

FS-EEP update there will be a slider to set a custom transition time, including the ability to disable transitions.

Heroes! 

Edited August 11, 2020 by Kyrie Deka

[NiranV Dean]

On 8/10/2020 at 4:38 PM, Ansariel Hiller said:

And you have bugs in your viewer we already fixed years ago - shouldn't you be ashamed right now? How can you dare to have your users live with these bugs for years? In your position I would be careful who you start fingerpointing at, especially if your viewer contains an actual TPVP violation you only get away with because apparently Oz doesn't seem to care since it only affects 250 users or so...

But for now I am happily waiting for your lesson about release managent which is most likely coming up next - I'm sure it will be good for a laugh or giggle at least!

Bugs that haven't been reported so far then and thus haven't had any relevance since no one has yet noticed them. You know to fix a bug i first have to know about it, either by finding it myself or by having someone report it and so far all bugs that i could fix in any way or another were fixed at some point and usually pretty fast depending on their priority, things like breaking high resolution snapshots~ 

For a Viewer with so many old unfixed bugs there's an awful amount of complains about missing features from Firestorm rather than these bugs. I suppose missing features from Firestorm are more important than these old bugs. 🤨

And for someone with a TPVD violating Viewer i've done quite a lot of extra work to make it compliant with LL's excessive and sometimes quite stupid rules and requirements. Any such violation is either an oversight (bug) or is subject to this "greyzone" called Shared Experience that has been discussed up and down already. So how about you name me such a violation? Apparently you seem to know of at least one. I'm sure it would be in everyone's interest to get any such violation fixed asap.

Edited August 11, 2020 by NiranV Dean

[Ansariel Hiller]

6 minutes ago, NiranV Dean said:

Bugs that haven't been reported so far then and thus haven't had any relevance since no one has yet noticed them. You know to fix a bug i first have to know about it, either by finding it myself or by having someone report it and so far all bugs that i could fix in any way or another were fixed at some point and usually pretty fast depending on their priority, things like breaking high resolution snapshots~

Do you have some broken record or what's your obsession with high resolution snapshots? But hey, most people haven't noticed that or it wasn't relevant for them, so everything ok for 99% of the users. Aside from that there are several issues in the viewer you would notice in daily use and are even reported to the LL JIRA - if you would actually use the viewer for things other than pushing pixels in the UI or tweak stuff for creating videos to brag with!

6 minutes ago, NiranV Dean said:

For someone with a TPVD violating Viewer i've done quite a lot of extra work to make it compliant with LL's excessive and sometimes quite stupid rules and requirements. Any such violation is either an oversight (bug) or is subject to this "greyzone" called Shared Experience that has been discussed up and down already. So how about you name me such a violation? Apparently you seem to know of at least one. I'm sure it would be in everyone's interest to get any such violation fixed asap.

You must be kidding, right? Everyone knows how you changed the complexity calculation the way you think it should be because you couldn't be asked to wait until LL overhauls the calculation. What does the viewer source code say about the calculation again? Exactly:

/*****************************************************************
     * This calculation should not be modified by third party viewers,
     * since it is used to limit rendering and should be uniform for
     * everyone. If you have suggested improvements, submit them to
     * the official viewer for consideration.
     *****************************************************************

Wanna bet if Firestorm or another TPV with more than 250 users will pull such a stunt, they won't get away with a simple warning in the TPVD? Maybe we actually should and see if we can force a reaction from Oz, affecting your viewer as well...

 

 

[NiranV Dean]

1 hour ago, Ansariel Hiller said:

Do you have some broken record or what's your obsession with high resolution snapshots? But hey, most people haven't noticed that or it wasn't relevant for them, so everything ok for 99% of the users. Aside from that there are several issues in the viewer you would notice in daily use and are even reported to the LL JIRA - if you would actually use the viewer for things other than pushing pixels in the UI or tweak stuff for creating videos to brag with!

Oh those! I thought you were talking about things that are broken in the Viewer... not the server... or the content... or literally everything else! For only 1% there were quite a lot of people complaining, i guess you have had more users than i thought. Of course its bragging to you, you know some people do it to get the best image possible for their blog, photo shooting or whatever? There's little in bragging when even hardware from 2011 can do high resolution snapshots up to 6K easily at "ultra" settings. You don't go out for photo shooting in real life to take the first picture you get don't you? You'd probably want to take a few and take only the best one, would be quite stupid if your perfect pictures were ruined by a crack in your lens.

1 hour ago, Ansariel Hiller said:

You must be kidding, right? Everyone knows how you changed the complexity calculation the way you think it should be because you couldn't be asked to wait until LL overhauls the calculation. What does the viewer source code say about the calculation again? Exactly:

/*****************************************************************
     * This calculation should not be modified by third party viewers,
     * since it is used to limit rendering and should be uniform for
     * everyone. If you have suggested improvements, submit them to
     * the official viewer for consideration.
     *****************************************************************

Yes and i don't make a secret out of it. That comment doesn't say i'm not allowed to. I know what it means to do something not allowed, i've been warned by Oz before, pretty sure if he really didn't want me to touch it, he would have told me by now. Besides, the complexity thing is a very touchy topic. I've tried for months on end to prove that complexity is in a bad shape, nothing was done about it until after i did it myself, i had to make the entire meeting talk about how ***** the current complexity system is preemptively, to even get Oz to listen to what all the fuzz was about. Funny how i've never seen you do something about it. I suppose that's part of the whole "picking your fights" thing Jessica talked about, you just do whatever is easy for you it seems, i suppose that's what you become when you have more than 250 users.

Edited August 11, 2020 by NiranV Dean

[Ardy Lay]

I see what you mean.

Edited August 12, 2020 by Ardy Lay

[Ansariel Hiller]

On 8/11/2020 at 11:29 PM, NiranV Dean said:

Oh those! I thought you were talking about things that are broken in the Viewer... not the server... or the content... or literally everything else! For only 1% there were quite a lot of people complaining, i guess you have had more users than i thought. Of course its bragging to you, you know some people do it to get the best image possible for their blog, photo shooting or whatever? There's little in bragging when even hardware from 2011 can do high resolution snapshots up to 6K easily at "ultra" settings. You don't go out for photo shooting in real life to take the first picture you get don't you? You'd probably want to take a few and take only the best one, would be quite stupid if your perfect pictures were ruined by a crack in your lens.

You know you are getting boring, right? You said bugs are only relevant if you know about them, otherwise it's acceptable to release with bugs - what you said in a nutshell basically. This leads to the simple conclusion that there was no snapshot bug for the vast majority of our users. And those actually affected still had the chance of rolling back to an older version. What I was referring to are bugs that are inside your viewer you would have noticed at some point if you were actually using the viewer. Anyway, since I'm getting bored and we're not getting anywhere here: Brag on, Wayne!

On 8/11/2020 at 11:29 PM, NiranV Dean said:

Yes and i don't make a secret out of it. That comment doesn't say i'm not allowed to. I know what it means to do something not allowed, i've been warned by Oz before, pretty sure if he really didn't want me to touch it, he would have told me by now. Besides, the complexity thing is a very touchy topic. I've tried for months on end to prove that complexity is in a bad shape, nothing was done about it until after i did it myself, i had to make the entire meeting talk about how ***** the current complexity system is preemptively, to even get Oz to listen to what all the fuzz was about. Funny how i've never seen you do something about it. I suppose that's part of the whole "picking your fights" thing Jessica talked about, you just do whatever is easy for you it seems, i suppose that's what you become when you have more than 250 users.

...and since Oz actually approved your arbitrary changes to the complexity calculation, there is a big fat warning in front of your viewer in the TPVD. You are so funny at times! You don't need to be a rocket scientist to figure out those changes are actually a blatant violation of the TPVP and you only got away with it because nobody at the Lab cares about that small number of users. Anyway: I leave you with your thoughts that taking things into your own hands if you are explicitly asked to not do so is a great idea!

[Ardy Lay]

If a software bug is when the software deviates from the product documentation and “Our source code is our documentation.” then there are no bugs.  I suppose JIRA is full of feature requests.

Edited August 14, 2020 by Ardy Lay

[NiranV Dean]

9 hours ago, Ansariel Hiller said:

You know you are getting boring, right? You said bugs are only relevant if you know about them, otherwise it's acceptable to release with bugs - what you said in a nutshell basically. This leads to the simple conclusion that there was no snapshot bug for the vast majority of our users. And those actually affected still had the chance of rolling back to an older version. What I was referring to are bugs that are inside your viewer you would have noticed at some point if you were actually using the viewer. Anyway, since I'm getting bored and we're not getting anywhere here: Brag on, Wayne!

...and since Oz actually approved your arbitrary changes to the complexity calculation, there is a big fat warning in front of your viewer in the TPVD. You are so funny at times! You don't need to be a rocket scientist to figure out those changes are actually a blatant violation of the TPVP and you only got away with it because nobody at the Lab cares about that small number of users. Anyway: I leave you with your thoughts that taking things into your own hands if you are explicitly asked to not do so is a great idea!

What, i can't read your salty whining from behind my 12K snapshots. All i see is mimimi.

Oz's warning about complexity in itself ironically is misleading, it gives people the impression that dark magic is being used here. You could as well put a warning on every Viewer using RLVa, not supporting EEP or lagging behind the Official code for months. Spoiler that would be every single Viewer. If the Lab cares as little as you say, why haven't they simply shot me down? With only 250 users no one would care right?

Doing these things is the very part of Open Source Development, they expect us to deliver at the very least a proof-of-concept working featureset if we want something implemented, better yet a ready feature, how are we going to deliver something big like that without testing these things first mh? I changed complexity because i didn't want to wait for another round of bad ARC calculations that are just going to end up being disregarded because it was already said they are not aiming to punish bad content. Which begs the question why even have complexity in the first place if bad content is just going to end up being valued the same as good content again ~ which was the whole reason this complexity system was bad in the first place. My users are happy with the changes, i'm happy, it does what its supposed to do, identify and clip out overly excessive avatars.

7 hours ago, Ardy Lay said:

If a software bug is when the software deviates from the product documentation and “Our source code is our documentation.” then there are no bugs.  I suppose JIRA is full of feature requests.

Except that almost no one can read said documentation... and what about comments that state something contradictory to what the code says? Is that considered misleading or is this a bug?

Edited August 14, 2020 by NiranV Dean

[Ardy Lay]

1 hour ago, NiranV Dean said:

Except that almost no one can read said documentation... and what about comments that state something contradictory to what the code says? Is that considered misleading or is this a bug?

Sounds like you agree with me.  I requested LL provide documentation for their viewer and was told “Our source code is our documentation.”

[Ardy Lay]

I can’t imagine Niran’s viewer is having any influence on what users of LL’s viewer see in world.  If a third party viewer somehow does something that changes how LL’s viewer renders an object or avatar, by, say, utilizing invalid attachment points or malformed object geometry, then I would say that viewer is violating the shared experience clause.

[animats]

Meanwhile, any progress on "default mainland EEP diffuse lighting is too dark?"

[NiranV Dean]

1 hour ago, animats said:

Meanwhile, any progress on "default mainland EEP diffuse lighting is too dark?"

I'm not 100% sure but i think the specularity changes (which are actually lighting changes) did uncap the lighting making it possibly brighter again. At least that's what it felt like.

1 hour ago, Ardy Lay said:

I can’t imagine Niran’s viewer is having any influence on what users of LL’s viewer see in world.  If a third party viewer somehow does something that changes how LL’s viewer renders an object or avatar, by, say, utilizing invalid attachment points or malformed object geometry, then I would say that viewer is violating the shared experience clause.

That's correct. While my Viewer does some things differently (arguably all Viewers do with some things) none of my changes impact other Viewers or users, at least not directly.

Technically you could say that building something with different default settings (say altered glow settings) could make creations render as intended on one Viewer while it doesn't look as good on another. HOWEVER, if you pull through with that, changing settings as a whole wouldn't be allowed and the moment you do so, you'd have to be locked out of content creation. Who even says that person who made that lamp didn't ramp up glow settings like crazy and then created something with his settings in mind, no one can control that. It's the same with additional features like Screen Space Reflections. I'm bringing SSR up specifically because i was told that SSR was removed from Firestorm due to exactly this very reasoning (and people complained about an optional feature apparently).

I'd even go as far as leaning far out of the window and say that Firestorm of all the Viewers has potentially the biggest impact on users, especially those not using Firestorm. *caugh* LookAt Names

Edited August 14, 2020 by NiranV Dean

[animats]

54 minutes ago, NiranV Dean said:

I'm not 100% sure but i think the specularity changes (which are actually lighting changes) did uncap the lighting making it possibly brighter again. At least that's what it felt like.

Technically you could say that building something with different default settings (say altered glow settings) could make creations render as intended on one Viewer while it doesn't look as good on another.

The diffuse lighting problem is that the initial default environment for EEP has too dim a diffuse value. The default has been fixed, but nothing propagates it to all of mainland automatically. So we're stuck on dim. As a workaround, users are setting their personal environment to "Midday", which overrides most of the parcel and region EEP settings. So by the time this is fixed, EEP may be irrelevant. I was talking to a sim owner whose mall is nearly pitch black at night in an EEP viewer on Ultra. He had no idea that was the case, because he's always on "Midday". He's been struggling to get tenants.

Excessive glow is a problem. A good start would be for the viewer to not enable glow for an object face until its texture is loaded. That would avoid "giant glowing blobs" during texture loading. Visit Oxymoron for a particularly severe case of this problem. That's a sci-fi sim with a bit of glow in the roads. During loading, the entire road surface lights up in painfully glowing white until the textures come in. After loading, only a few small areas of glow remain, and it looks fine.

Edited August 14, 2020 by animats

[Stevie Davros]

On 8/10/2020 at 12:29 PM, Anne Cord said:

Thanks Steve for your advice but I can find no way to get the sun to light up (regain the glow) when it rises above the horizon, no matter where I drag and no matter how I move it.

I believe this is a bug and I'll just have to wait until it's fixed. Luckily it's not very important. Twice a day when for no known reason the glow shifts from the sun to the moon or vice versa,  causinga sudden change in the overall lighting, noticed only by me.

I think there should be two glow settings, one for the sun and one for the moon. That the moon now captures the glow from time to time is probably a  bug, not a feature.

 

 

All the settings in the sky interact with each other. It can be tricky to get the sky to look the way you want. The best bet is to start with a good sky someone else made and amend it to suit your desires.  I agree that they need to sort out the Sun issue. The Sun glow does not show in the entire sky as it does in reality - especially at sunrise or sunset. If you make the Sun Glow negative, the clouds on the other side of the sky look as they do in RL at sunset, but the sun and clouds near it are plunged into an unnatural darkness.  If you leave the Sun Glow where the sun is with positive values, the sun is washed out when you set the slider to give the far side of the sky some light...

[Pat Perth]

This question concerns the day-cycle editor.

When the sun rises above the horizon the world immediately lights up; when the sun falls below the horizon the world suddenly turns dark. I suppose there is some combination of settings that make the light change around sunrise and around sunset a more gradual process, but I cannot find those settings. Does anybody have any advice?

[Stevie Davros]

I have discovered another issue with the new graphics possibilities of EEP. Part of the promotion about EEP from LL has been the ability to create custom graphics to replace the sun and moon for selling in Marketplace, there is really no limit to one's imagination here. I had though to create a pack of graphics people could buy to add to their existing favourite sky settings files. All well and good you might think. If I put a pack into Marketplace with a collection of graphics textures set to No Transfer and embed them in sky files to demonstrate them, all set to No Transfer all seems ok.  The problem is that anyone can them make their own sky file, or use an existing one, add in the No Transfer sun or moon graphic, and then transfer that sky file with anyone they like.  So it becomes impossible to provide a texture graphic for mix-n-match use as the No Transfer capability is so easily circumvented.  The only work around I see is to only provide No Transfer sky files with the sun and moon graphics already embedded, and not allow people to use the graphics in their own sky files, but instead ask them to amend the provided sky file to the way they want it to look. Your thoughts?

[Stevie Davros]

3 minutes ago, Pat Perth said:

This question concerns the day-cycle editor.

When the sun rises above the horizon the world immediately lights up; when the sun falls below the horizon the world suddenly turns dark. I suppose there is some combination of settings that make the light change around sunrise and around sunset a more gradual process, but I cannot find those settings. Does anybody have any advice?

You need to go into Atmosphere & Lighting and change a bunch of the settings there to get the result you seek, but they would need manual tweaking for each slight change in the sun position. There does not seem to be any linking between the settings in Atmosphere & Lighting and Sun & Moon. Of course in RL everything is closely interlinked.

[Ardy Lay]

When they get all these new issues ironed out I am going to submit a feature request to have the naturally occurring flash of green called the true green of hope restored to SL.  

[Pat Perth]

42 minutes ago, Stevie Davros said:

You need to go into Atmosphere & Lighting and change a bunch of the settings there to get the result you seek, but they would need manual tweaking for each slight change in the sun position. There does not seem to be any linking between the settings in Atmosphere & Lighting and Sun & Moon. Of course in RL everything is closely interlinked.

Yes of course I know that. I already said there must be a bunch of settings that need to be changed.

[jillgoodgal]

9 minutes ago, Pat Perth said:

Yes of course I know that. I already said there must be a bunch of settings that need to be changed.

What I think you are asking is how to change the sky color and lighting by time in the day/night cycle. What I found is that although the dark/light change is indeed rather abrupt, you can set several different sky and horizon colors/lighting, and the EEP does make a gradual change between these.  So, if you make the sky a gradually darkening blue or bluegreen as the cycle progresses into sunset, and then something similar, maybe adding a little redness for the sunrise, the sky can still appear a little lighter after sunset, as full darkness comes on. Also vary the star brightness, and use haze if that works for your scene, as that will give a diffuse lighting appearance.  I have about seven different sky combinations for our Starfleet Headquarters San Francisco setting at ground level to make these changes in sky lighting

[Whirly Fizzle]

3 hours ago, Stevie Davros said:

I have discovered another issue with the new graphics possibilities of EEP. Part of the promotion about EEP from LL has been the ability to create custom graphics to replace the sun and moon for selling in Marketplace, there is really no limit to one's imagination here. I had though to create a pack of graphics people could buy to add to their existing favourite sky settings files. All well and good you might think. If I put a pack into Marketplace with a collection of graphics textures set to No Transfer and embed them in sky files to demonstrate them, all set to No Transfer all seems ok.  The problem is that anyone can them make their own sky file, or use an existing one, add in the No Transfer sun or moon graphic, and then transfer that sky file with anyone they like.  So it becomes impossible to provide a texture graphic for mix-n-match use as the No Transfer capability is so easily circumvented.  The only work around I see is to only provide No Transfer sky files with the sun and moon graphics already embedded, and not allow people to use the graphics in their own sky files, but instead ask them to amend the provided sky file to the way they want it to look. Your thoughts?

I filed this bug a while ago on the LL JIRA: BUG-228974 - [EEP] EEP settings do not respect texture permissions
The bug isn't public because it's a permission issue.

To be honest, I'm not actually sure if this is technically a bug, because creating skin assets using no copy to you or no transfer to you textures behaves in the same way - the resulting skins are full perm.
The same behaviour happens with eye, hairbase & system clothing assets you create with non-full perm textures you are not the creator of & as far as I can tell, it's always behaved this way.
When it comes to textures, permissions are pretty meaningless to be honest.

[Stevie Davros]

32 minutes ago, Whirly Fizzle said:

I filed this bug a while ago on the LL JIRA: BUG-228974 - [EEP] EEP settings do not respect texture permissions
The bug isn't public because it's a permission issue.

To be honest, I'm not actually sure if this is technically a bug, because creating skin assets using no copy to you or no transfer to you textures behaves in the same way - the resulting skins are full perm.
The same behaviour happens with eye, hairbase & system clothing assets you create with non-full perm textures you are not the creator of & as far as I can tell, it's always behaved this way.
When it comes to textures, permissions are pretty meaningless to be honest.

Thanks for the reply, yeah I have figured that might be the case. My textures held only by me but referenced in my sky files are confirmed as No Transfer and I have not figured any way that could be circumvented at least. The sky files I sell and their saved-as alterations remain No Transfer.  With some effort on the part of the purchaser, they can put in all their sky settings manually and change the sky I supply to have the look they want. It would have been way easier for them to be able to slap in the graphic, such is life.