As suggested by @Mugen87here starting a new thread to discuss issues with SSAA once again.
I am facing the issue affecting a resulting image contrast when using SSAA with Gamma. I did try using suggestions described here, however, in my case passing {type: FloatType} doesn’t have any effects.
Here on the picture below left is RenderPass + SSAA + Gamma, right is RenderPass + Gamma.
I tried to reproduce my issue in this fiddle: Edit fiddle - JSFiddle - Code Playground but for some reason the shader throws an error (I will try to update it a bit later to make it work), but at least you can see what I am doing. The general idea is that I use GLTF model paired with HDR light. Once light is loaded I am updating models EnvMaps and changing scene environment.
I do really need SSAA and I am hoping you can help me to fix the issue with colors.
There were multiple minor issues in the code. The most important one:
Use OutputPass instead of GammaCorrectionShader to get color space conversion and tone mapping right.
Use Scene.background to define a background color. If you define a raw clear color value without THREE.Color, you bypass the internal color management meaning you have to define colors in the correct color space on app level.
PMREMGenerator is now integrated in the renderer. When using environment maps, you don’t have to work with it on app level anymore.
So to clarify, your issue was related to mismatched color spaces and missing tone mapping.
BTW: It’s best to check out the official examples if you need a code template since they are always based on the latest API.
Thanks! I am trying it now and for some reason my TS project doesn’t see OutputPass in the postprocessing folder, even though it is there. All other passes and shaders are visible.
I think a live example like before would be helpful in order to investigate the issue. Maybe updating the fiddle from earlier posts (Edit fiddle - JSFiddle - Code Playground) would be best.
My (TS) code looks almost identical to the original fiddle I provided here, however, it works in contrast with the fiddle. I do not understand why the fiddle doesn’t work since it is almost the same. The only difference is that I use loadAsync for textures instead of load in my code.
I compared our fiddles and it seems that apart of differences in loading and changing envMaps, there is also a difference in the HDR files we are using. My one was generated by HDRLightStudio and exported with the following settings:
When I use this file in your fiddle it also crashes with the following error (like my original one):
Program Info Log: Fragment shader is not compiled.
FRAGMENT
ERROR: 0:477: 'assign' : cannot convert from 'const int' to 'highp float'
Because of this HDR file, in my code I had to traverse all meshes and update their envMap. If I don’t update their envMap metallic surfaces become black. While in your fiddle you simply specified texture.mapping = THREE.EquirectangularReflectionMapping; and it worked well.
To be honest, I am a bit lost… I will investigate further.
Another problem is that I need to have a transparent background in my project, but setting scene.background kills the transparency. You mentioned that I need to define color space on app level, do you have an example of how to do it?
Hi @Mugen87. I was finally able to reproduce my issue in the fiddle: Edit fiddle - JSFiddle - Code Playground. I am using SSAA + OutputPass on MouseUp and RenderPass on MouseDown.
Also, I’m setting scene.background as you suggested and I removed PMREMGenerator.
Please suggest if I am missing something?
Also, I want my background to be transparent. How can I achieve this? You mentioned that I need to set the background, otherwise I “have to define colors in the correct color space on app level”. Could you please suggest when I can read about it?
You are not setting up the render target for the effect composer correctly. It should be a half float render target but you are using THREE.UnsignedByteType. This breaks the entire HDR workflow.
TBH, I recommend you only setup the composer in this way if you really know what you are doing. There is no need to manually setup the render target for the composer anyway for your use case as well as manually set the size of each pass. Please don’t do that since this makes no sense.
It also makes no sense to configure MSAA for render targets if you use SSAA. You have done this by defining a value for the samples parameter.
Transparent backgrounds tend to be problematic. They are not always required since a pure WebGL solution is often possible. Do you mind explaining your use case?
TBH, I recommend you only setup the composer in this way if you really know what you are doing. There is no need to manually setup the render target for the composer anyway for your use case as well as manually set the size of each pass. Please don’t do that since this makes no sense.
I have checked it some time ago, but I will do it once again.
Transparent backgrounds tends to be problematic. They are not always required since a pure WebGL solution is often possible. Do you mind explaining your use case?
I am building a 3D viewer that can be embedded into other sites. Depending on the design of these sites, I can enable or disable a transparent background. This feature is quite important. In addition we offer an augmented reality feature that also needs a transparent background. Are there any specific best practices I should consider when developing transparent backgrounds?