[TRACKER] iOS rendering bugs related to half_float precision issues

[clayjohn]

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:

1. 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.

2. 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

   	#ifdef JAVASCRIPT_ENABLED
   	config.support_half_float_vertices = false;
   	#else
   	//every other platform, be it mobile or desktop, supports this (even if not in the GLES2 spec).
   	config.support_half_float_vertices = true;
   	#endif

config.support_half_float_vertices = true;
//every platform should support this except web, iOS has issues with their support, so disable
#ifdef JAVASCRIPT_ENABLED
	config.support_half_float_vertices = false;
#endif 
#ifdef IPHONE_ENABLED
	config.support_half_float_vertices = false;
#endif

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

[lawnjelly]

3.2.2 beta 2

Good news is, we got this in 3.2.2 beta 2.

Bad news is, I made a boo-boo 😊 , and although there is a disable_half_float project setting in rendering/gles2/debug/disable_half_float, it is actually trying to read it from a mistyped version (batching instead of debug) in the code. So changing this project setting currently won't have any effect.

Instructions

However, you can still get it to work, but you have to work around my mistake by editing your project.godot, which is a text file, that contains lots of info about your project.

You just need to add the setting manually in your project.godot:

[rendering]

gles2/batching/disable_half_float=true

(if the [rendering] section already exists, then only gles2/batching/disable_half_float=true should be added under it)

Feedback

Please let us know how you get on, whether this fixes any issues on iOS for you. Again, apologies for making such silly mistake!

[oeleo1]

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.