godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
86.22k stars 19.18k forks source link

Render "GLES2" does not draw Polygon2D on Android #35772

Open Valeryn4 opened 4 years ago

Valeryn4 commented 4 years ago

godot 3.1.2-stable

Android 6.0 (BF166_BOOST3-SE_L010)

If you use the "GLES2" render, then the Polygon2D is not drawn! If you use the "GLES3" render, then everything works Textures imported as Loss

GLES2: image of GLES2

GLES3: image of GLES3

PS: I need it for beautiful animations

Valeryn4 commented 4 years ago

scenes that use Polygon2D produce the following errors:

PS D:\Dev\Android\Sdk\platform-tools> adb logcat -s godot
--------- beginning of system
--------- beginning of crash
--------- beginning of main
01-31 18:18:08.860 27637 27656 I godot   : Loading Android module: org/godotengine/godot/GodotShare
01-31 18:18:08.886 27637 27656 I godot   : Loading Android module: org/godotengine/godot/GodotAdMob
01-31 18:18:09.028 27637 27656 I godot   : Godot Engine v3.1.2.stable.custom_build - https://godotengine.org
01-31 18:18:09.039 27637 27656 I godot   : OpenGL ES 2.0 Renderer: Mali-T720
01-31 18:18:09.775 27637 27656 D godot   : AdMob: init with content rating options
01-31 18:18:09.775 27637 27656 I godot   : AdMobAPI: Init adMob
01-31 18:18:09.779 27637 27656 I godot   : Global INFO: fps change to 60
01-31 18:18:11.560 27637 27656 E godot   : **ERROR**: R float texture not supported, converting to RGB8.
01-31 18:18:11.560 27637 27656 E godot   :    At: drivers\gles2\rasterizer_storage_gles2.cpp:162:_get_gl_image_and_format() - R float texture not supported, converting to RGB8.
01-31 18:18:11.560 27637 27656 E godot   : **ERROR**: R float texture not supported, converting to RGB8.
01-31 18:18:11.560 27637 27656 E godot   :    At: drivers\gles2\rasterizer_storage_gles2.cpp:162:_get_gl_image_and_format() - R float texture not supported, converting to RGB8.
01-31 18:18:11.733 27637 27656 E godot   : **ERROR**: RG float texture not supported, converting to RGB8.
01-31 18:18:11.733 27637 27656 E godot   :    At: drivers\gles2\rasterizer_storage_gles2.cpp:176:_get_gl_image_and_format() - RG float texture not supported, converting to RGB8.
01-31 18:18:11.734 27637 27656 E godot   : **ERROR**: RG float texture not supported, converting to RGB8.
01-31 18:18:11.734 27637 27656 E godot   :    At: drivers\gles2\rasterizer_storage_gles2.cpp:176:_get_gl_image_and_format() - RG float texture not supported, converting to RGB8.
01-31 18:18:11.739 27637 27656 E godot   : **ERROR**: R float texture not supported, converting to RGB8.
01-31 18:18:11.739 27637 27656 E godot   :    At: drivers\gles2\rasterizer_storage_gles2.cpp:162:_get_gl_image_and_format() - R float texture not supported, converting to RGB8.
01-31 18:18:11.739 27637 27656 E godot   : **ERROR**: R float texture not supported, converting to RGB8.
01-31 18:18:11.739 27637 27656 E godot   :    At: drivers\gles2\rasterizer_storage_gles2.cpp:162:_get_gl_image_and_format() - R float texture not supported, converting to RGB8.
lawnjelly commented 4 years ago

Info that might be useful, what Android devices are you testing this on, and does it work when you try in 3.2? (Or just a simple test case for Polygon2D that exhibits the problem, not necessarily your whole project)

akien-mga commented 4 years ago

Could you try with Godot 3.2? This might have been fixed in that release.

Valeryn4 commented 4 years ago

Could you try with Godot 3.2? This might have been fixed in that release.

I have not migrated to version 3.2 yet. Because it is necessary to rebuild all the templates. In a couple of days I can check.

what Android devices

BOOST3-SE Android 6.0 (BF166_BOOST3-SE_L010)

Valeryn4 commented 4 years ago

Could you try with Godot 3.2? This might have been fixed in that release.

There is a problem on 3.2

To repeat the error you need: Cut a part of the texture using "Polygon 2D"

clayjohn commented 4 years ago

@Valeryn4 I wonder if the issue is caused by the texture and not by the Polygon2D. From the errors you reported it looks like you are using a unique type of texture.

Could you please try running the same scene with the texture removed to see if the issue is still present?

Valeryn4 commented 4 years ago

@Valeryn4 I wonder if the issue is caused by the texture and not by the Polygon2D. From the errors you reported it looks like you are using a unique type of texture.

Could you please try running the same scene with the texture removed to see if the issue is still present?

EXAMPLE PROJECT: https://github.com/Valeryn4/GodotPolygon2DBug

I am using PNG. Imported as "LOSS" or as "VRAM" I found that this error is present only if "Skeleton2D" + "Polygon2D" is used

If you do not use Skeleton2D and do not deform the polygon, there is no such problem.

Valeryn4 commented 4 years ago

There is no such problem on a PC.

Also, the "GLES3" render does not send the correct colors to some devices. If you use a polygon and a skeleton: Auto-Test in FireBase (Google Pixel) https://youtu.be/jCuqU34pT7I

image

clayjohn commented 4 years ago

@Valeryn4 Thanks for the updates! I did a search through existing issues as well and it seems that using Skeleton2D with Polygon2D has many bugs right now. For example, your color bug is reported here https://github.com/godotengine/godot/issues/27919

Soon I will put together a big issue tracker so we can properly track all the Skeleton2D issues on GLES2. At this point it appears we need to do a lot of work to make it work properly.

Valeryn4 commented 4 years ago

What is the alternative? I have a lot of similar animation!: https://www.youtube.com/watch?v=4YfzkH1RHsg It works well in GLES3, but does not work in GLES2

clayjohn commented 4 years ago

@Valeryn4 Unfortunately, I don't think there is an alternative right now. It seems that it is just broken. It needs to be fixed.

Valeryn4 commented 4 years ago

Using the stable version, I expect everything to work there. And it is not very pleasant to detect malfunctions at the end of development.

Why are there no warnings when using the Polygon or Skeleton that it does not work on some devices?

Such errors incur losses during development, and not a word about them in the documentation.

clayjohn commented 4 years ago

Unfortunately it is a bug the we were unaware of. Because we did not know it was a problem we couldn't fix it in time for 3.2.

Please understand that Godot is not made by a large professional team. It is made by a handful of volunteers. It is impossible for us to test every combination on every device out there. Unfortunately it turns out that your device has trouble with this combination of features.

We will do our best to fix it in a reasonable amount of time.

Valeryn4 commented 4 years ago

I came across such a device! HUAWEI Y6 Prime 2018 It does not work "GLES3" with 4096 textures. (mode : 2d, expand) - Game freezes on boot splash It WORKS "GLES2" with textures 4096 and Skeleton2D.

example GLES3: https://github.com/Valeryn4/GodotBugGles3OnSpecificDevice Skype_Picture_2020_02_11T11_22_02_355Z

Other games on this device work!

$ ./adb logcat -s godot
--------- beginning of crash
--------- beginning of system
--------- beginning of main
02-11 15:27:17.463 29923 29985 I godot   : Godot Engine v3.2.stable.official - https://godotengine.org
02-11 15:27:17.510 29923 29985 I godot   : OpenGL ES 3.0 Renderer: Adreno (TM) 308
02-11 15:27:17.605 29923 29985 I godot   :

may be its bug?

lawnjelly commented 4 years ago

There's a good chance we can fix this as part of the new GLES2 2d renderer, I'm putting in software transform paths for most of the primitives (have done rects, lines, ninepatches so far). May possibly be done by 3.2.2 although it depends how many other regressions there are to fix.

Valeryn4 commented 4 years ago

There's a good chance we can fix this as part of the new GLES2 2d renderer, I'm putting in software transform paths for most of the primitives (have done rects, lines, ninepatches so far). May possibly be done by 3.2.2 although it depends how many other regressions there are to fix.

Are there any developments? I would make my own changes to the source code for my product, which is already in the release and does not work on GLES2

lawnjelly commented 4 years ago

Sorry this has been delayed both by a rewrite (because regressions were very problematic to deal with in the old version) and more importantly dealing with coronavirus.

New version only deals with rects so far and I'd prefer to get that in testing before the other primitives (the logic is simpler for quads). So I can't give any promises or definite timescale for this. On the other hand if you are prepared to build from source you will be able to get it sooner when I do get around to it (probably some weeks yet). In any case I'll try and link to this thread when there is something available.

Valeryn4 commented 4 years ago

On the other hand if you are prepared to build from source you will be able to get it sooner when I do get around to it (probably some weeks yet). In any case I'll try and link to this thread when there is something available.

sure! I can build from source codes) I am building a build with 3D disabled, on android and iOS)

Valeryn4 commented 4 years ago

I had to abandon the skeleton = ( Now the animation is not very beautiful = (

OLD (Use skeleton): https://www.youtube.com/watch?v=4YfzkH1RHsg NEW (Disable skeleton): https://youtu.be/rbvmBEoqrFk Compare: https://youtu.be/-KKi4FZG2m8

Valeryn4 commented 4 years ago

Sorry this has been delayed both by a rewrite (because regressions were very problematic to deal with in the old version) and more importantly dealing with coronavirus.

New version only deals with rects so far and I'd prefer to get that in testing before the other primitives (the logic is simpler for quads). So I can't give any promises or definite timescale for this. On the other hand if you are prepared to build from source you will be able to get it sooner when I do get around to it (probably some weeks yet). In any case I'll try and link to this thread when there is something available.

Good afternoon! Any news?)

lawnjelly commented 4 years ago

Good afternoon! Any news?)

I won't be able to look at it until the regressions for the rects are all sorted, and as it requires writing a completely new path it is quite likely to be after 3.2.2. There's also the need to start work on a GLES renderer for 4.x.

It needs two features essentially: 1) Poly software batching 2) New software skinning path

dnadan2 commented 3 years ago

Hey, just wanted to bump this thread and ask if it did get fixed in 3.2.2 or if it is planned in future releases? I am still seeing it not draw and wanted to check its the same issue.

Calinou commented 3 years ago

@dnadan2 This wasn't fixed in 3.2.2, and it may take a while for it to be fixed. That said, since Polygon2D rendering is much slower than sprite rendering, you may not want to rely on it on mobile in the first place anyway.

kjav commented 3 years ago

Hi @Calinou - does this mean that 2d skeletons are currently not supported on GLES 2? Thanks. Edit: By that I mean on android, due to this bug.

Calinou commented 3 years ago

@kjav Probably not, there are other issues about it already: https://github.com/godotengine/godot/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+gles2+skeleton2d

lawnjelly commented 3 years ago

Had forgotten about this, but it's on my roadmap. Currently I've had a pause on work on the batching until 3.2.3 is released (which is meant to be just bug fixes for 3.2.2), then a couple of PRs for light angles need to get merged and I can get stuck in for GLES3 batching. This has taken a lot longer than expected due to the delay on 3.2.3.

Once GLES2 and GLES3 both use the unified path I can look at batching the other primitives and this software path. Otherwise it just means trying to work on several different forks simultaneously and having to throw out a lot of work.

akien-mga commented 3 years ago

Note that you can still work on features/PRs which will be merged after 3.2.3 is released. The earliest we get big changes merged in prevision of 3.2.4, the better :)

lawnjelly commented 3 years ago

I've now added a software path as part of batching in #42119. It will probably be a project setting to switch between sofware and hardware 2d skinning.

Sorry took so long to get round to it! :blush:

akien-mga commented 3 years ago

Fixed by #42119.

Valeryn4 commented 2 years ago

BUMP! @akien-mga The problem is still not resolved. The error pops up on some devices.

Version 3.3 image image

lawnjelly commented 2 years ago

Make sure you have batching on, and your project setting rendering/2d/options/use_software_skinning switched on, also make sure the Polygon2D does not have anti-aliasing switched on (I don't think this ever is active on mobile but it's worth checking if it disrupts the software skinning path, it may well do). I'll double check what happens if AA is switched on in this case.

EDIT: Have checked and logic seems correct with anti-aliasing, this shouldn't affect it. And it uses the correct software transform path when tested on desktop with AA switched on.

Maybe it's your version, I wonder if anything here was fixed between 3.3 and 3.3.3 (which is the current stable version).

There were some small fixes since 3.3, it may be fixed in 3.3.3. But either way it would be good to have the small part of this project that is used that has this problem so I can investigate. I'll try your old MRP but I'm pretty sure that worked fine as I was using it to test things as I developed. There might be some small difference in your shipping version from the MRP.

I've retested your old MRP with the fuzzy yellow blob and it works fine using the software skinning. So maybe there is something specific in your shipping project. Also confirm that your texture size is 2048x2048 or lower and is power of 2 sized. We are assuming here that the problem is skinning, but it could be something else like the texture that is not supported on that hardware.

clayjohn commented 2 years ago

@lawnjelly I don't think we have added checks everywhere for hardware dependent max texture sizes. So it could indeed be a texture size issue.