-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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.
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
[TRACKER] iOS rendering bugs related to half_float precision issues #38441
Comments
3.2.2 beta 2Good news is, we got this in 3.2.2 beta 2. Bad news is, I made a boo-boo 😊 , and although there is a InstructionsHowever, you can still get it to work, but you have to work around my mistake by editing your You just need to add the setting manually in your
(if the FeedbackPlease let us know how you get on, whether this fixes any issues on iOS for you. Again, apologies for making such silly mistake! |
Feedback: after some quick testing on iOS: Yes, it does fix the CPUParticles on iOS for GLES2 and that's great news. Regarding performance, no perceivable difference on my project of batching vs non-batching on iOS but I have to spend some more time on that. It looks like the batching prevents some of the stutter I see with GLES2 (GLES3 is far better on iOS). Haven't tried Android yet. |
That's good, the half float change seems to be successful. We'll have to see about the most sensible way to roll it out long term (in terms of detection, or just platform specific defaults), and test whether it is a case of half float not being supported in GLES2, or just the wrong constant. In terms of performance, it could be that you are not drawcall limited, it depends on the game. I'm happy to help with specific performance issues in games, although probably github isn't the best place. Maybe https://godotforums.org/ ? |
All fixed as of 3.4 with #54229 which disables half float on iOS by default. |
Recently, while investigating a potential batching bug, @lawnjelly traced back rendering issues on an iOS device to the use of half float UVs. When an ArrayMesh is set to use compression, it will use half float (16 bit) formats instead of full float (32 bit). This cuts the size of the mesh in half, but can result in precision issues. The use of half floats is enabled by the extension
GL_HALF_FLOAT_OES
which is "available" on all GLES2 devices. I say "available" because iOS register the extension and present it as available, but silently fail when half floats are used in a vertex format. This comment #38318 (comment) presents a partial fix to the problem, but a more robust fix is needed.I see two avenues to approach this problem:
The issues are most obvious when rendering a mesh after having rendered certain GUI primitives. This seems to suggest that mixing half_floats and floats is a problem (e.g. the vertex buffer doesn't like switching between the two formats. This may require us to allocate more buffers to keep things clearly separated.
The issue clearly stems from the use of
GL_HALF_FLOAT_OES
, so an obvious (but not necessarily optimal) fix would be to force iOS devices to never use half floats here:godot/drivers/gles2/rasterizer_storage_gles2.cpp
Lines 5953 to 5958 in 8426ed2
This solution, while easy, would result in iOS devices never compressing vertex data, which will unnecessarily increase the amount of VRAM used.
The following issues appear to stem from this particular issue and will likely be solved by the fixes above:
GLES2 Batching + CPUParticles2D texture + Label = Rendering issue on iOS #38318
CPUParticle2D Textures Don't Render on iOS After Screen Reading Shader #38211
CPUParticles2D renders wrong with GLES2 on iOS if scene uses NinePatchRect, Panel, Button or ProgressBar #32837
The following issues may come from this particular issue and may be solved by the fixes above:
iOS GLES2 3D Rendering is Broken #27191
iOS error 500 when using GLES2 (related to #31471) #31907
The text was updated successfully, but these errors were encountered: