Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Artifacts on Android GLES2 with PanoramaSky #43667

Closed
Filippopotamus opened this issue Nov 19, 2020 · 5 comments
Closed

Artifacts on Android GLES2 with PanoramaSky #43667

Filippopotamus opened this issue Nov 19, 2020 · 5 comments
Assignees
@clayjohn @lawnjelly
Labels
bug platform:android topic:rendering
Milestone
3.2

Comments

@Filippopotamus
Copy link

Filippopotamus commented Nov 19, 2020 •
edited
Loading

Godot version:
3.2.3

OS/device including version:
Android, Pixel 2, GLES2

Issue description:
On Editor:
image

On Android:
screen

Artifacts on objects when WorldEnvironment has a PanoramaSky. If WorldEnvironment is set to color only, this does not happen. There is a ticket related to this (#33633) which says it is fixed by enabling High Precision Float in GLES2 for Android, however it does not seem to fix it. This issues is not present on Desktop or iOS (or any other platform I am aware of)

Steps to reproduce:

  1. Create scene and add a sphere and camera
  2. Add SpatialMaterial to sphere
  3. Add WorldEnvironment to scene and add Environment
  4. Select Background->Mode = Sky
  5. Add new ProceduralSky or add a PanoramaSky
  6. Run project on Android device

Minimal reproduction project:
Repro Project (Includes .apk)
Repro Project (No .apk)
@Filippopotamus Filippopotamus mentioned this issue Nov 19, 2020
Closed
@akien-mga akien-mga added this to the 3.2 milestone Nov 19, 2020
@volzhs
Copy link
Contributor

volzhs commented Nov 19, 2020

probably related to #37673

@Filippopotamus
Copy link
Author

Filippopotamus commented Nov 19, 2020 •
edited
Loading

As @NeoSpark314 mentioned on #33633, the Level 1 of the Sky cubemap is black.

Level 0:
Level0

Level 1:
image

So that seems to be the issue. However, I am not quite sure how to solve it. There is some special code for LOD1 on rasterizer_storage_gles2.cpp:

		if (lod == 1) {
			//bind panorama for smaller lods

			glActiveTexture(GL_TEXTURE0);
			glBindTexture(GL_TEXTURE_CUBE_MAP, sky->radiance);
			shaders.cubemap_filter.set_conditional(CubemapFilterShaderGLES2::USE_SOURCE_PANORAMA, false);
			shaders.cubemap_filter.set_conditional(CubemapFilterShaderGLES2::USE_DIRECT_WRITE, false);
			shaders.cubemap_filter.bind();
		}

But I am not sure this is the culprit. I tried messing around with it with no success.

@Filippopotamus
Copy link
Author

Any news on this?

@Calinou
Copy link
Member

Calinou commented Dec 14, 2020

Any news on this?

As far as I know, nobody has found a fix to this issue yet.

@Chaosus Chaosus mentioned this issue Dec 18, 2020
Merged
@Tubeliar Tubeliar mentioned this issue Dec 20, 2020
Closed
ForestKatsch added a commit to ForestKatsch/godot that referenced this issue Dec 20, 2020
@ForestKatsch
Fixes godotengine#43667.
8825aa8 
The root cause of the issue is that OpenGL ES 2 does not support the `textureCubeLod` function.
There are (optional) extensions to support this, but they don't appear to be exposed with the ES2 renderer (even though the hardware needed to support LOD features are certainly available.)
The existing shim in `drivers/gles2/shaders/cubemap_filter.glsl` just creates a macro:

```
 #define textureCubeLod(img, coord, lod) textureCube(img, coord)
```

But the third parameter of `textureCube` is actually a mip bias, not an absolute mip level.
(And it doesn't seem to work regardless.)
In this specific case, the `cubemap_filter` should only sample from the first level of the "source" panorama cubemap.
In lieu of a method to force a lod level of zero, I've chosen to comment out the switchover from a 2D equirectangular panorama to the cubemap version of the same image, therefore always sampling roughness values from the 2D equirectangular panorama.
This may cause additional artifacts or issues across the seam, but at least it prevents the glaringly obvious black areas.

---

This same issue (no fragment texture LOD support) has rather large repercussions elsewhere too; it means materials with larger cubemap density (i.e. planar or distant objects) will be far rougher than expected.
Since GLES 3 appears to properly support fragment `texture*Lod` functions, switching to the GLES 3 backend would solve this problem.

---

Root cause discovered with help from @kaadmy.
@akien-mga
Copy link
Member

Fixed by #44489.

@yjh0502 yjh0502 mentioned this issue Aug 16, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@clayjohn clayjohn

@lawnjelly lawnjelly

Labels
bug platform:android topic:rendering
Projects
None yet
Milestone
3.2
Development

Successfully merging a pull request may close this issue.

fixes #10946, auto-reload with external editor yjh0502/godot
6 participants
@Calinou @Filippopotamus @akien-mga @volzhs @clayjohn @lawnjelly