Fix the bogus, zero cloud scroll rate in default EE sky settings. #892
Conversation
Obvioulsy, there has been a typo done when copying WL default sky parameters to EE ones. This causes "static" and quite unrealistic clouds when this default setting is used as a base for a new sky setting, and we see this bad static sky resurfacing now with PBR and its "adjusted" (more like hacked, but this is another story) mid-day sky setting. Let's fix this typo once and for all in LL's code base (most TPVs have it fixed already, and this ever since EEP got released). @ll: please also fix the cloud scroll rate in the PBR mid-day inventory setting accordingly.
|
Thank you for the contribution! |
|
Maint X looks like a good place for this fix to release it sooner. |
|
If this is a typo in defaults, it might need adjustments server side as well. |
There was a problem hiding this comment.
It's fine to not default to a static sky, but the new default midday should remain static until we have support for HDRI import/export. It's built to be a close analog to the HDRI found here:
https://polyhaven.com/a/cloud_layers
Artists need a consistent environment to author content against that they can approximate in their editor of choice, and ever-changing cloud coverage makes that impossible.
And yes, using the existing sky system to approximate HDR skies is a hack. There are better procedural sky models to choose from, but HDRI support is probably the way to go between here and there.
I beg to differ. New features should not break old contents. SL is not Sansar: SL got a huge amount of legacy contents that should render just as fine as it did in the past (including when using legacy EE or even WL settings) when you introduce new features. Yes, it's a PITA, but it is how SLers expect SL to evolute, and I personally don't want to see LL killing SL (like they failed Sansar, albeit for different causes) with such an enormous mistake as ruining legacy contents rendering ! In the same vein, simply introducing a hacked mid-day setting to try and make up for the ugly and totally unrealistic blue hue seen on shiny objects (PBR and legacy alike) is not going to do it ! (see my reply to Dan Linden about viewer 7.1.3.7821226606 in this feedback thread)
Are you kidding me (or rather us all SLers) ?!? O.O If a 3D artist needs a specific sky setting to develop their art, they are competent enough to design their own sky with a fixed cloud coverage, but if they think that their piece of "art" needs a static cloud coverage when sold out to other SLers in order to look "good", then I'm afraid their art is just good for the trash ! Who, in SL, as a user, wants, say, a pool for their garden that will only look good with a static sky setting: what a beautiful sight indeed as this garden under an alien/unrealistic sky, where you cannot even enjoy looking at the clouds, see them change, and move, the coverage change too ! This makes strictly no sense whatsoever. If your aim is to make SL look ugly, with static clouds, then I am pretty sure many, many, many SLers (and me among them) will get angry. As for HDRI, do you have the slightest idea of how many SLers even got an HDRI-capable monitor ?... I'd bet in the 1-2% range. If you want to kill SL for everyone else, then go for it ! Please, reconsider before it is too late... |
Sounds like "Please use Nam's Optimal Skin WL" 2.0...
I have a HDR compatible displays, but guess what: I have HDR disabled because it causes nothing but trouble - not particularly SL as I haven't even tested it with SL, but all kind of various applications and games. |
|
You're of course free to make Ctrl+Shift+Y apply the legacy midday in your viewer if you so choose. The purpose of having a sky that can be recreated in third party tools isn't to make content that only looks good with that sky, it's to provide a baseline for artists to author content against so they can have a WYSIWYG experience while making materials in third party tools. There was a bug with that sky where it was overbrightened and was creating an overbearing blue sheen, but that has been resolved. I'd like to clear up some misconceptions folks seem to have on HDR rendering vs HDR displays vs HDRI images... HDR rendering (which SL now supports) simply refers to the use of render targets and lighting models that allow a wider range of color values than 8-bit per component normalized [0-1]. The render targets used by the renderer are now 16-bit floating point per component, and the final image is converted back to a range the monitor can display via a tonemapper and exposure. This is why the new viewer no longer has color banding in the lighting or in the sky, and it's necessary to properly support the GLTF specification. It's also standard practice for any render engine currently in use today. HDRI stands for High Dynamic Range Image, but it's become shorthand for equirectangular HDR environment maps. What HDRI import/export support in SL would look like is the ability to save 360 snapshots in the EXR format, skipping the tonemapping and exposure step and preserving the raw lighting data. This is what the HDRI's you get from photoscans basically are -- raw camera sensor data encoded in a standard format. Edit to add: import would look like the ability to import an .exr to replace the WL sky via a sky setting. HDR displays are not suppored by SL and likely won't be be until well after we support Vulkan. The standards for those displays are all over the place right now, which is why, as Ansariel says, they tend to cause problems when enabled. You also seem to have a misconception on who I am -- I worked on SL from 2005 until 2014. I was instrumental in introducing mesh support and deferred rendering, I helped integrate Windlight. I worked on Sansar for 4 years with the hopes that the tech would make it back to SL. When Sansar was sold off I was very happy to come back to SL (if we end up hanging out inworld I might tell you some stories, but I don't like to air dirty laundry). I absolutely appreciate the need to not break legacy content, but that doesn't mean SL has to look the same today as it did 10 years ago. The arguments against HDR rendering are the same as the arguments against deferred rendering. Yes, content looks different, but part of keeping a platform relevant for many decades is evolving with the times. 10 years ago, you could expect artists to spend many hours tailoring their content for your engine, but today, the expectation is that your engine supports a standard such as GLTF or USD and that content can be quickly imported as-is. These standards don't just define the content itself, they also define how that content must be displayed. The changes to rendering of legacy content are the minimum required to make that content usable alongside GLTF compliant content. Thanks for taking the time to read my reply. |
You know, you sound to me like someone very creator-centric (what Sansar was too, thus my reference to it), and not at all SL-user-centric... The problem with PBR, is that it was entirely discussed in SL creators meetings, not with SL users, and this sadly shows now with pretty unacceptable (but fixable, I'm sure) flaws for the said users. Had these meetings been held in chat rather than on voice (can't understand spoken English well enough, sorry), I would have gladly participated to try and argue constructively with the said creators, as a (modest) creator myself, a long-time, multi-usage (socializing, RPing, sailing, flying, etc) SLer, and a programmer who (modestly, but still, along 88 weekly releases) helped the transition to Windlight, and then later on to EEP, as some people could not quite run these well with their computer, back then. But let's go back to the sky setting in question: I see no problem with it as long as it is not made the default sky for everyone, ruining the computer-generated clouds moving and changing with WL scroll rates. My suggestion to you is therefore to simply rename this PBR mid-day setting into "PBR creator's static mid-day sky" or something in that vein, and then provide, as the default mid-day the same setting but with clouds scrolling enabled. You are also welcome to provide more PBR-adapted settings for Sunset, Sunrise, Midnight, if they can help you (barely) attenuate that ugly blue hue, but seeing how it renders both PBR and legacy materials alike, this is not a proper solution either. See my updated post in this feedback thread, for which I added a screen shot taken with your "artists" setting (poor artists, their creations will really look ugly). Obviously, this blue hue is totally unrealistic: I never saw a white metal polished object turn that blue and that dark under a mid-day blue sky (or at whatever time of the day).
I'm well aware about the more accurate render targets, thank you: they are not at all at play in our issues with PBR rendering.
Please, do tell your little creators clique that I, for one (and I'm sure I am not alone), certainly do NOT want to see the SL sky becoming fully static, without moving and changing clouds and clouds density: SL is not a game and what you are proposing here is basically what we see in shooter action AAA games where nobody cares about of the sky, of course. When I sail in SL, I want to see the sky changing slowly, with pretty clouds (and FYI, I even kept the pre-Windlight legacy low altitude clouds in my viewer, where you can optionally enable them and even change their average altitude: they look very pretty in some scenes !). So, pretty please, make HDRI skies an option with WL/EE skies as a fallback !
I am a little reassured on this front, then, but it does not address the tone mapping issue in PBR rendering, making scenes too dark, including at midday !
Same with you and who I am. But in my case, I do not make any assumption and simply draw conclusions from our past interactions (one of which was interesting, even if rather fruitless in the end, the only other rather disappointing and snappy from your part, but I will keep this private "conversation" private)...
I would be glad to meet in-world, when convenient for us both, if you do wish to get the full grasp of my (and many SLers alike) problems about PBR (I could show you places where it really sucks rocks, to the point of being unacceptable, in its current state). In the mean time, look at my activity from my profile on the SL forum: many of my "recent" posts there have been dealing with PBR: you will see that I am not at all trying to destroy anyone's work at LL and even less badmouth anyone, and on the contrary I give level-headed, balanced responses to the less enthusiastic people. The only problem I have is that, currently, PBR is, at best, in a beta state, and not ready for the hardcore SL users crowd (who, thankfully, do not use LL's own viewer and since the most popular TPV has wisely kept its PBR version at an alpha stage for now, this buys you a little more time to solve the remaining issues). Had PBR been kept in beta until all serious rendering problems had been addressed, the enthusiasm about it would have been almost unanimous !
Indeed !!! It should just look better, like when Windlight replaced the first renderer ! I already told you in our first conversation: I am an eager early adopter, but I am also totally unforgiving towards regressions, and so far the regressions seen in the PBR renderer are unacceptable. PS: please, see this bug report about reflection disabling: if we could disable them without loosing the scene lighting, then the "blue hue" would be "solved" for places with ALM-only shinies and no sky-shielding reflection probes. See also this suggestion of mine, which could potentially work around other cases, from the objects' owner side. |
|
This pull request is stale because it has been open 30 days with no activity. Remove stale label or comment or it will be closed in 7 days |
Obvioulsy, there has been a typo done when copying WL default sky parameters to EE ones. This causes "static" and quite unrealistic clouds when this default setting is used as a base for a new sky setting, and we see this bad static sky resurfacing now with PBR and its "adjusted" (more like hacked, but this is another story) mid-day sky setting.
Let's fix this typo once and for all in LL's code base (most TPVs have it fixed already, and this ever since EEP got released).
LL: please also fix the cloud scroll rate in the PBR mid-day inventory setting accordingly.