Closed candypheonixIO closed 3 years ago
Frooxius
commented
3 years ago Do you have any replication steps for this and samples? What were the textures loaded as?
Generally we recommend filling out the issue template rather than deleting it, otherwise we might not be able help.
candypheonixIO
commented
3 years ago It can be recreated in any world just by setting the skybox texture to uncompressed, you can visually see all color data being further compressed into a shorter dynamic range.
The textures are loaded by whatever default format Neos uses for both compressed and uncompressed HDRi textures (RGBHalf & RGBA32), but it's RGBA32 what the texture is converted to when set to 'uncompressed' that causes the HDRi texture to lose its dynamic range, and a lot of color accuracy. Instead, I would expect uncompressed to retain the dynamic range, and increase color accuracy in the texture.
Frooxius
commented
3 years ago Can you please fill the standard bug reproduction template for this and provide some sample skybox that exhibits this problem? We need details to handle issues like this, ideally have some comparison for reference to know what the expected look is. A lot of the skyboxes in worlds aren't HDR to begin with and I'm not too certain what compression artifacts do you mean exactly.
It sounds like you might be forcing the HDR texture to be LDR instead, but without clear reproduction steps, it's hard to say.
candypheonixIO
commented
3 years ago Setting HDRi textures to 'uncompressed' using the 'uncompressed' checkbox in the provided StaticTexture2D Component will cause the HDRi texture to lose its dynamic range, and crunch color data more.
The texture should keep its dynamic range, and bring back color accuracy, reducing color 'banding' or a 'jpeg/jpg compression effect'.
Skybox HDRi compressed and uncompressed GIF recording Lightmap HDRi compressed and uncompressed GIF recording
n/a
Smol🍪#5247
shiftyscales
commented
3 years ago As Frooxius had asked, could you please also provide some sample skybox that exhibits this problem, or otherwise, provide "any HDRi texture, skybox, or lightmap created by "The Lightmapper" blender addon" so our developers have something to work with to investigate the issue? @candypheonixIO
candypheonixIO
commented
3 years ago I've already stated, this happens with any HDRi texture.
neosdb:///30349b221187d2296aad5eb816cb673a32910caf6791f06b01487782f4bbdbd5.hdr neosdb:///d8c3bbd1d5e8fab602bdb1062699501da4a693b5667c8e82e7212a74f764544f.hdr These two provided directly from the Neos Essentials exhibit this issue.
https://hdrihaven.com/hdri/?c=skies&h=abandoned_tank_farm_04 This 3rd-party HDRi provided by HDRI HAVEN also exhibits this same issue.
This has nothing to do with specific textures, this is an issue with how Neos 'uncompresses' HDRi textures.
shiftyscales
commented
3 years ago I didn't say it did have anything to do with specific textures @candypheonixIO, all I had asked was that you provide one so that everything needed to investigate this issue is contained within this issue, and nobody has to do any digging (even if just slight) in order to demonstrate this issue.
This reduces the potential for friction/additional work on our end, and increases the likelihood your issue will be looked into, and addressed.
Similarly, if you even just provided a simple template world with such a skybox already pre-applied, marked the world orb as public, and posted the link to open it here, that would even further reduce any potential friction on investigating the issue.
candypheonixIO
commented
3 years ago You're right, you didn't say anything about it being an issue with a specific HDRi, tho, asking me to create a "sample world" with an HDRi sample set (skybox, and/or lightmaps) implies that it is. This is why I kept expressing this happens with any HDRi, anyone can go into anyone's, or their own personal world, or even open a 'basic empty' world and apply an HDRi skybox provided in the Neos Essintials, and use the "recreation steps" of simply setting the texture/skybox to 'uncompressed'. This is the same amount of work/"friction" even if I did make a sample world.
H3BO3
commented
3 years ago It really isn't. Providing something that can be used easily is extremely helpful, not to mention that it's known that it causes an issue - Suppose this didn't happen with any HDRi, but you assumed that it did, and then devs weren't able to replicate it. If they have a known "bad" file then they would have been able to, but now their time has been wasted trying to track down a vague replication case. There are multiple reasons why providing even just one file or link initially would have avoided all this.
candypheonixIO
commented
3 years ago But I didn't assume since I've gone through several HDRi's from different sources, i.e HDRI HAVEN, Neos Essentials, The Lightmapper. It's a "vague" replication case, because of how simple it is to replicate, and the amount of resources there are that can be used to replicate the same issue.
I'm sure there have been several cases of vague replication cases that are assumed will work for "anything", but when I've provided two, separate pieces of evidence of two different textures using the exact same HDRi format producing the same effect when 'uncompressed', then I can confidently say "this happens with any HDRi texture".
shiftyscales
commented
3 years ago You're right, you didn't say anything about it being an issue with a specific HDRi, tho, asking me to create a "sample world" with an HDRi sample set (skybox, and/or lightmaps) implies that it is. This is why I kept expressing this happens with any HDRi, anyone can go into anyone's, or their own personal world, or even open a 'basic empty' world and apply an HDRi skybox provided in the Neos Essintials, and use the "recreation steps" of simply setting the texture/skybox to 'uncompressed'. This is the same amount of work/"friction" even if I did make a sample world.
Consider it from the perspective of one of our developers, @candypheonixIO:
Compare that to:
It's a small detail, and doesn't take much time on its own, but it's also a small thing issue submitters can do to make the process easier in replication and testing- not just for this issue, but any issue. It all adds up. So no, it's not the same amount of work as if you had provided a sample as requested.
Just the fact alone that you hadn't initially used the issue template we provided meant that Frooxius had to take time out of his day to reply, and ask that you provide him the information you should have in the first place.
Being lazy in your issue submission just forwards more work onto the developers, and makes it less likely your issue will be looked at and addressed, because something that could have been a five minute tweak becomes something that spans over the course of multiple days and multiple replies.
You are doing yourself a favor by doing us a favor and making it easier for us to investigate and resolve your issues.
H3BO3
commented
3 years ago You missed the part where I said "suppose". It was a hypothetical and yet that was the only thing your response was about. I was attempting to generalize this to all issues and why having fast replication rather than having to dig through folders is important for devs.
I could, but I'm not going to go into detail about why having accessible data for replication on hand makes the process faster since Shifty has already addressed that.
candypheonixIO
commented
3 years ago You're right, it was a lazy first statement to the issue, that can be thanked for the simplicity of the issue. A good sample world would have been "The Viridian Islands", it provides two HDRi textures on the skybox that are affected.
@H3BO3 I did see the part where you said "Suppose", that hypothetical makes sense in most, if not all cases, though, this issue affected all HDRi textures, the only way it wouldn't show is if you were to use a .webp, .jpg, .png, .tif, or anything other than a proper .hdr texture.
I apologize for not using the template in the first place, I assumed from the simplicity and highly re-creatable nature of the issue that it wasn't necessary, that's on me.
H3BO3
commented
3 years ago Thank you for the apology, it's just that people can't always assume these things. Even if an issue sounds ludicrously simple, making the replication case as simple as possible is still important, and providing as much contextual information as you can (such as the bug information bullet points on the issue template). That way it can be isolated and iterated on repeatedly.
Frooxius
commented
3 years ago Fixed in 2021.6.7.794, HDR textures should now use RGBAHalf instead of RGBA32 which was removing all the HDR values. Thanks!
Recently using a lightmapping addon for blender, provides HDRi outputs for the lightmaps, when bringing them into neos, some of the color data is compressed similarly to JPG style of compression even though the original file does not show this compression. So to 'correct' this, I set the texture to 'Uncompressed' it seemingly makes the HDRi lose majority of light data, and makes the crunched colors worse.