Broken GLES2 render in Godot 3.4 and later on iOS due to Octahedral Compression

[SkanerSoft]

Godot version

3.4.2 and 3.5 beta 1

System information

iOS 15.2.1 / iPhone SE / OpenGL ES 2.0 Renderer: Apple A9 GPU

Issue description

When running the game on iOS, GLES2 rendering does not work correctly. I tried a variety of render settings, re-imported everything several times, but nothing helped. I have tried all versions of Godot since 3.4 to check at what point the rendering started to work incorrectly, however, in all versions the situation is the same.

On the video you can track the process of how it looks.

https://user-images.githubusercontent.com/13809475/151420521-a01c91e0-bb55-4235-9335-593ddb72cc9f.mp4

Also here are some screenshots. Sorry for the quality, I didn't make it.

Runs from Xcode

This project works great on Android, Windows, Linux, MacOS but is completely broken on iOS. Switching to GLES3 solves this problem, but the game starts to work very slowly (FPS drops a lot).

When starting the project, the console outputs this

*********** main.m
running app main
Path: /var/containers/Bundle/Application/141C6F1F-C05D-41A4-BAFE-8B9F9C1B4C81/Bunker.app
godot_iphone /var/containers/Bundle/Application/141C6F1F-C05D-41A4-BAFE-8B9F9C1B4C81/Bunker.app/Bunker
cwd /private/var/containers/Bundle/Application/141C6F1F-C05D-41A4-BAFE-8B9F9C1B4C81/Bunker.app
os created
setting data dir to /var/mobile/Containers/Data/Application/E8A36F7A-E7D7-49B6-AA65-3296D3C7DC04/Documents from /var/mobile/Containers/Data/Application/E8A36F7A-E7D7-49B6-AA65-3296D3C7DC04/Documents
setup 0
2022-01-27 19:12:00.839936+0300 Bunker[1369:282913] Metal API Validation Enabled
2022-01-27 19:12:00.977090+0300 Bunker[1369:282913] Setting up an OpenGL ES 2.0 context.
2022-01-27 19:12:00.977381+0300 Bunker[1369:282913] failed to make complete framebuffer object 8cd6
2022-01-27 19:12:00.977430+0300 Bunker[1369:282913] Failed to create frame buffer!
******** setting up keyboard input view
******** adding observer for keyboard show/hide

start animation!
2022-01-27 19:12:01.018063+0300 Bunker[1369:282913] ERROR: AudioOutputUnitStart failed, code: -50
2022-01-27 19:12:01.018145+0300 Bunker[1369:282913]    at: start (drivers/coreaudio/audio_driver_coreaudio.cpp:249) - AudioOutputUnitStart failed, code: -50
ERROR: AudioOutputUnitStart failed, code: -50
   at: start (drivers/coreaudio/audio_driver_coreaudio.cpp:249) - AudioOutputUnitStart failed, code: -50
2022-01-27 19:12:01.025181+0300 Bunker[1369:282913] Godot Engine v3.5.beta1.official.b9b23d222 - https://godotengine.org
Godot Engine v3.5.beta1.official.b9b23d222 - https://godotengine.org
2022-01-27 19:12:01.030797+0300 Bunker[1369:282913] OpenGL ES 2.0 Renderer: Apple A9 GPU
OpenGL ES 2.0 Renderer: Apple A9 GPU
2022-01-27 19:12:01.202877+0300 Bunker[1369:282913] 

When switching to a game scene with a loaded 3D level

(servers/visual/visual_server_scene.cpp:731) - Index p_surface = 0 is out of bounds (instance->materials.size() = 0).
ERROR: Index p_surface = 0 is out of bounds (instance->materials.size() = 0).
   at: instance_set_surface_material (servers/visual/visual_server_scene.cpp:731) - Index p_surface = 0 is out of bounds (instance->materials.size() = 0).
2022-01-27 19:12:39.319028+0300 Bunker[1369:282913] ERROR: Index p_surface = 0 is out of bounds (instance->materials.size() = 0).
2022-01-27 19:12:39.319089+0300 Bunker[1369:282913]    at: instance_set_surface_material (servers/visual/visual_server_scene.cpp:731) - Index p_surface = 0 is out of bounds (instance->materials.size() = 0).
ERROR: Index p_surface = 0 is out of bounds (instance->materials.size() = 0).
   at: instance_set_surface_material (servers/visual/visual_server_scene.cpp:731) - Index p_surface = 0 is out of bounds (instance->materials.size() = 0).

Endless spamming of bugs to the console (shown in the video video) throughout the game.

2022-01-27 19:16:12.030526+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.047285+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.065636+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.080681+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.097296+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.114506+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.130409+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.146974+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.164081+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.181806+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.197300+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.213994+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.230584+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.247444+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.264062+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.281690+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.298460+0300 Bunker[1369:282913] DrawView: 500 error
2022-01-27 19:16:12.314070+0300 Bunker[1369:282913] DrawView: 500 error

Steps to reproduce

Download and open the project from the archive.

The minimum project contains the most complete script for building the game.

Main level in res://levels/level_0.tscn

Rendering takes place on the scene res://scenes/game.tscn

Minimal reproduction project

Bunker_21.zip

[Calinou]

I have tried all versions of Godot since 3.3 to check at what point the rendering started to work incorrectly, however, in all versions the situation is the same.

This statement contradicts the issue title, which says that this bug only affects Godot 3.4.2 and later. Does this bug actually affect Godot 3.3 too?

[SkanerSoft]

I apologize, I mistyped, it should indicate 3.4. Corrected. I tried 3.4, 3.4.1, 3.4.2 and 3.5 (beta 1).

[Calinou]

@SkanerSoft Can you reproduce this in any of the 3.4 betas and RCs to determine when the regression started?

[SkanerSoft]

I'll try. It seems to me that if the problem exists in both 3.4 and 3.5, then intermediate versions between them will also contain it...

Well, it's time to download export templates =)

I will add the results only tomorrow, since the export templates for one version are downloaded for about 45 minutes.

[Calinou]

I'll try. It seems to me that if the problem exists in both 3.4 and 3.5, then intermediate versions between them will also contain it...

3.4 betas and RCs were released before 3.4.stable.

[lawnjelly]

At a guess, Octahedral compression? #46800 That's biggest change in 3D around then that springs to mind, and I don't know how tested it was on all hardware. You may be able to test this by switching off octahedral compression, re-importing and re-exporting, I don't know the details though.

Mind you it is also saying "Failed to create frame buffer", but it is mostly showing correctly. I guess bisecting is the only way to know.

Also, is there anything special about these objects that are corrupting in the scene? Are they animated for instance? It seems interesting that some objects seem to be rendering fine but some are corrupting.

[akien-mga]

I tried 3.4, 3.4.1, 3.4.2 and 3.5 (beta 1).

It's still not clear to me whether you tried Godot 3.3.x and it works fine there?

It's important to know if the issue is new in 3.4+ (i.e. a regression), or if the issue has always existed (in which case testing intermediate releases as suggested in https://github.com/godotengine/godot/issues/57322#issuecomment-1023561703 will not be of any use).

[SkanerSoft]

Objects are not animated, they break randomly. Some belong to the GridMap and some do not. You can try downloading the minimal project to see it from the inside.

Now my tests on previous versions.

3.4 beta 1 won't launch due to not being able to check file security on my mac.

The "Godot.app" file cannot be opened because Apple cannot scan it for malware.
This software needs to be updated. Contact the developer for details.

3.4 beta 2 The project does not work correctly, or it gives an error when launched (see screenshot).

3.4 beta 3 Looking forward to downloading the export templates. The speed is very low ... I will write later.

[SkanerSoft]

I tried 3.4, 3.4.1, 3.4.2 and 3.5 (beta 1).

It's still not clear to me whether you tried Godot 3.3.x and it works fine there?

3.3 can't open project, everything looks broken. Some of the models are not displayed. The feeling that something is not supported in it from what is in the project. And there is no way to create the game again in the old version, since this is a very large project.

[SkanerSoft]

The project has been made for more than a year, it has a lot of models, details that will be very difficult to re-import again, since you will have to re-create every 3D object in the game. This is an unbearable amount, because the project has long existed for the players.

[lawnjelly]

Everytime you try a new version, it's probably a good idea to delete your .import folder and let the IDE reimport everything.

It is highly possible the problem is happening via the imported resources. That error in 3.4 beta 2 could be from using later imported assets with an earlier version of the engine.

And don't panic BTW, it's highly likely it's super easy to fix, it's just pinning down what this particular device has problems with is tricky (we don't have many mac contributors and even less that have access to iPhones). :slightly_smiling_face:

[SkanerSoft]

Yes, I delete import files before each opening. However, the project does not start. In addition, it looks incorrect in the editor itself (for version 3.4 beta 2). Version 3.4 beta 3 is just downloading. Internet speed is extremely slow...

[SkanerSoft]

And don't panic

I understand. Thanks. It's just that the game has a huge audience (millions of people) on Android, and many players have asked for iPhone support, which I can't provide because of this... I would like to use the 3.5+ features to provide the best experience for the players. As soon as I download 3.4 beta 3, I will share the results of testing. For 3.4 beta 2, everything is bad.

[lawnjelly]

I'm guessing you have access to the Mac and iPhone there which is helpful. Am looking at the project now trying to work out some likely culprits.

Some things I would try in project settings, to at least eliminate them as the cause:

• rendering->threads->thread_model change this to to single_safe. multithreaded is not as well tested.
• rendering->gles2->compatibility->disable_half_float set this to on, just in case the iOS override isn't working for some reason (half float will cause this kind of bug)
• rendering->limits->buffers set these to defaults
• rendering->misc->split_stream worth a try just in case it fixes some bug in the octahedral
• rendering->quality->skinning->force_software_skinning set to on. I'm not clear on whether you are using any skinning, but software skinning is more likely to work than hardware.

It looks like the octahedral vertex compression may be difficult to test, because there is no global on / off switch that I can see, it is done at import. You can turn it on and off in the import settings for a mesh ( @lyuma also informs me there is some kind of global setting for importing meshes in ProjectSettings->Import_defaults ), but your meshes seem to be baked into tscn files, so I don't know if it is possible to edit their vertex format (I'm not familiar with the octahedral compression and the importing process, it is completely outside my area, but it has caused several similar corruption bugs, which is why it would be nice to eliminate it as a cause).

One thing you could try is create a new project and just try a mesh either imported with and without octahedral, and see if it works on the device in both cases.

I would also try turning off the lightmap (if you are using one) and see if that fixes the corruption.

Also anything that uses more than 65535 vertex indices is a possible culprit (some hardware doesn't support this).

Also you could try hiding everything in the scene, then gradually bringing objects back into the scene to try and work out if there is any particular object / objects this is happening on, or if it is truly just random. Truly random corruption is more rare, it might suggest a threading issue, or the GPU has got into a corrupted state. From the video it looks suspiciously like a particular object is coming into view and triggering it. Or else a buffer overrun maybe.

Custom shaders (I don't know if you use any) are also particularly prone to problems on mobile hardware.

Sorry if this sounds a bit "shotgun" with the approach, but there a number of different causes of this kind of thing, and letting you know the most likely culprits enables you to do some detective work. I can't do anything my end because I do not have the devices.

[SkanerSoft]

Version 3.4 beta 3 produces the same result.

Now I will try to enter the settings that you said to check everything. It will be long... =)

[SkanerSoft]

For today I give up. The project did not start in any intermediate version. Buffer errors everywhere.

As a result, I again reached version 3.5 beta 1

I left only one mesh (ground) on the stage and the project still did not start. And now it finally crashes, without even reaching the render.

Errors in the console when trying to run.

*********** main.m
running app main
Path: /var/containers/Bundle/Application/8948DA8A-051A-45C6-959F-C103D336ECCE/Bunker_22.app
godot_iphone /var/containers/Bundle/Application/8948DA8A-051A-45C6-959F-C103D336ECCE/Bunker_22.app/Bunker_22
cwd /private/var/containers/Bundle/Application/8948DA8A-051A-45C6-959F-C103D336ECCE/Bunker_22.app
os created
setting data dir to /var/mobile/Containers/Data/Application/0A128652-C84B-49FE-B0D6-51A4A6526B21/Documents from /var/mobile/Containers/Data/Application/0A128652-C84B-49FE-B0D6-51A4A6526B21/Documents
setup 0
2022-01-28 16:36:57.202697+0300 Bunker_22[509:25076] Metal API Validation Enabled
2022-01-28 16:36:57.340939+0300 Bunker_22[509:25076] Setting up an OpenGL ES 2.0 context.
2022-01-28 16:36:57.341241+0300 Bunker_22[509:25076] failed to make complete framebuffer object 8cd6
2022-01-28 16:36:57.341290+0300 Bunker_22[509:25076] Failed to create frame buffer!
******** setting up keyboard input view
******** adding observer for keyboard show/hide
start animation!
2022-01-28 16:36:57.378979+0300 Bunker_22[509:25076] ERROR: AudioOutputUnitStart failed, code: -50
2022-01-28 16:36:57.379070+0300 Bunker_22[509:25076]    at: start (drivers/coreaudio/audio_driver_coreaudio.cpp:249) - AudioOutputUnitStart failed, code: -50
ERROR: AudioOutputUnitStart failed, code: -50
   at: start (drivers/coreaudio/audio_driver_coreaudio.cpp:249) - AudioOutputUnitStart failed, code: -50
2022-01-28 16:36:57.382773+0300 Bunker_22[509:25076] Godot Engine v3.5.beta1.official.b9b23d222 - https://godotengine.org
Godot Engine v3.5.beta1.official.b9b23d222 - https://godotengine.org
2022-01-28 16:36:57.394280+0300 Bunker_22[509:25076] OpenGL ES 2.0 Renderer: Apple A9 GPU
OpenGL ES 2.0 Renderer: Apple A9 GPU
2022-01-28 16:36:57.569652+0300 Bunker_22[509:25076] 

2022-01-28 16:36:58.566629+0300 Bunker_22[509:25297] Execution of the command buffer was aborted due to an error during execution. Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)
2022-01-28 16:36:58.566812+0300 Bunker_22[509:25297] Execution of the command buffer was aborted due to an error during execution. Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)
2022-01-28 16:36:58.567249+0300 Bunker_22[509:25297] GLDRendererMetal command buffer completion error: Error Domain=MTLCommandBufferErrorDomain Code=2 "Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)" UserInfo={NSLocalizedDescription=Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)}
2022-01-28 16:36:58.567843+0300 Bunker_22[509:25076] DrawView: 500 error
2022-01-28 16:36:58.585304+0300 Bunker_22[509:25076] DrawView: 500 error
2022-01-28 16:36:58.588912+0300 Bunker_22[509:25293] Execution of the command buffer was aborted due to an error during execution. Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)
2022-01-28 16:36:58.589062+0300 Bunker_22[509:25293] Execution of the command buffer was aborted due to an error during execution. Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)
2022-01-28 16:36:58.589391+0300 Bunker_22[509:25293] GLDRendererMetal command buffer completion error: Error Domain=MTLCommandBufferErrorDomain Code=2 "Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)" UserInfo={NSLocalizedDescription=Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)}
2022-01-28 16:36:58.599696+0300 Bunker_22[509:25297] Execution of the command buffer was aborted due to an error during execution. Ignored (for causing prior/excessive GPU errors) (00000004:kIOGPUCommandBufferCallbackErrorSubmissionsIgnored)
2022-01-28 16:36:58.599860+0300 Bunker_22[509:25297] Execution of the command buffer was aborted due to an error during execution. Ignored (for causing prior/excessive GPU errors) (00000004:kIOGPUCommandBufferCallbackErrorSubmissionsIgnored)
2022-01-28 16:36:58.599930+0300 Bunker_22[509:25297] Execution of the command buffer was aborted due to an error during execution. Ignored (for causing prior/excessive GPU errors) (00000004:kIOGPUCommandBufferCallbackErrorSubmissionsIgnored)
2022-01-28 16:36:58.599976+0300 Bunker_22[509:25297] Execution of the command buffer was aborted due to an error during execution. Ignored (for causing prior/excessive GPU errors) (00000004:kIOGPUCommandBufferCallbackErrorSubmissionsIgnored)
2022-01-28 16:36:58.600087+0300 Bunker_22[509:25297dyld4 config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib
] GLDRendererMetal command buffer completion error: Error Domain=MTLCommandBufferErrorDomain Code=4 "Ignored (for causing prior/excessive GPU errors) (00000004:kIOGPUCommandBufferCallbackErrorSubmissionsIgnored)" UserInfo={NSLocalizedDescription=Ignored (for causing prior/excessive GPU errors) (00000004:kIOGPUCommandBufferCallbackErrorSubmissionsIgnored)}
2022-01-28 16:36:58.600247+0300 Bunker_22[509:25076] Terminating due to blacklisting by kernel driver

[SkanerSoft]

The smallest project.

Bunker_21.zip

[SkanerSoft]

So, I tried to re-import new models that were created in the same way as the previous ones. This time I imported the same model with different parameters and the result showed up immediately.

The screenshot shows the two models and the differences in settings (yes, just one tick).

And now how it looks on the phone.

https://user-images.githubusercontent.com/13809475/151659005-12554eaa-0b41-4e04-bb22-e1ee457b8c7d.mp4

[SkanerSoft]

@lawnjelly If this can be fixed without re-importing all game assets, that would be great. Because the game is displayed normally everywhere, except for the iPhone...

[SkanerSoft]

I will wait for Monday to get some answer on the solution.

[clayjohn]

Cc @The-o-king

[SkanerSoft]

Ok, I spent a whole day testing and yes, it is 100% "Octahedral Compression", after re-creating the assets and re-importing into the game with "Octahedral Compression" disabled, the whole game began to display correctly on all devices. Apparently, there are many weeks ahead of recreating gaming assets... well, the reason has become clear. Hope this bug gets fixed. As a recommendation, you can turn it off by default, since many people have no idea about such subtleties and the technical side of the issue.

[akien-mga]

@SkanerSoft I might be missing something as I'm not very familiar with this asset pipeline, but why would you need to recreate your assets to work this around? Isn't it sufficient to re-import all your models with Octahedral Compression disabled? I.e. select all 3D assets (glTF, Collada, etc.), go to import tab, untick the option and press "Re-Import".

[SkanerSoft]

@akien-mga The trouble is that my assets do not lie in the form of separate files. They are literally inside tscn files... It was my mistake when I originally designed the game's architecture)

[lawnjelly]

@akien-mga The trouble is that my assets do not lie in the form of separate files. They are literally inside tscn files... It was my mistake when I originally designed the game's architecture)

I don't know if this works as I didn't know it existed, but if you look in project_settings/import_defaults tab, and select importer Scene, there is a checkbox for octahedral compression. Sounds worth a try at least, maybe this will re-import meshes in the tscn files?

If not, then presumably we should have some mechanism for re-importing meshes in tscn files, or at least a warning. :thinking:

[SkanerSoft]

The tscn files are not imported at all, so this won't work. Of course, I immediately unchecked the compression box, only now for all game objects I will have to repeat "open blender -> export object -> open Godot -> import glTF -> copy mesh -> paste mesh into the desired object -> save -> rebake the shadows"...

Inside my scenes are meshes already imported and modified by the engine.

[Zireael07]

I don't get it... WHY are your gltf in your scene files?

[SkanerSoft]

Ok, look this =)

test.zip

UPD: This makes the project cleaner, there are no heaps of extra files. Plus less redundant information.

[akien-mga]

UPD: This makes the project cleaner, there are no heaps of extra files. Plus less redundant information.

It's tangential to this issue (octahedral compression needs to be fixed not to produce these bugs), but be aware that with this practice you are saving 3D mesh data as text in tscn files, when you could be using it from binary data in .glb, with a lot more flexibility to reimport everything on the fly if you need to change anything (like import settings here, or modify your mesh data, animations, etc.).

I don't have the original glb to compare, but see here the extra size that you get in a .tscn file from encoding mesh data as a byte array (the .tscn file has lines with 1 million characters). I converted it to .scn for comparison (the size of .tscn + .glb should be similar to that .scn):

-rw-r--r-- 1 akien akien 168K Feb  1 14:39 kosmonavt_1.scn
-rw-r--r-- 1 akien akien 1,2M Feb  1  2022 kosmonavt_1.tscn

[akien-mga]

BTW, since the issue is specific to iOS, you could also test to see if the compatibility/disable_half_float.iOS project setting makes a difference. It might be that octahedral compression requires half float support to work well (but in turns half float seem to create issues on some iOS devices).

[SkanerSoft]

compatibility/disable_half_float.iOS

Tried it didn't help.

data in .glb

Yes, I already understood that it is better to store all objects next to the scenes. There will be more files, and a little less ease of editing (glb cannot be edited in the engine (for example, duplicate some object inside (for example, a tree in a forest or a chandelier in an apartment, if a forest or apartment is a single glb))),

UPD: I checked again, yes, each file will have to be exported separately. It's literally thousands of gltf files =(

[The-O-King]

Hello! Sorry I just saw this right now (not sure how I missed the notification before) but I'll see if I can look into this by the end of the week - so after reading the thread my understanding is that when the project is opened directly as it is stored in the .zip file, in even the latest version of Godot, when exported to the iPhone, things are broken? But reimporting the assets without octahedral compression makes things work again? Is that correct?

So I think we may be looking at two problems:

1. In general octahedral compression does not work on iPhone under GLES2
2. There is an issue where a project being opened up which was not using octahedral compression on it's assets has broken rendering (perhaps somewhere a flag is being set which is making the renderer think octahedral is being used on these assets when it should not)

Is this the most recent minimal example of the bug found at this comment https://github.com/godotengine/godot/issues/57322#issuecomment-1024280728?

I didn't have an iPhone to test octahedral compression on during it's development to run into this issue, but I may be able to access a mac/iPhone later on and see if I can reproduce this (not sure if I will have access to anything as old as an A9 though)

Let me know if I've missed anything

[SkanerSoft]

One project test.zip

Two project min_project.zip

Hey! Here is an exact example, there are two objects, they are signed in the scene, one with compression and one without it. Here are screenshots of what it looks like on iPhone and Android. This time I took my wife's Android, and it turned out that her phone also had problems. There are no such problems on my Android. I have nokia 7.1.

On the iPhone, the second model is not displayed at all, and after about 10 seconds, the game crashes with an error accessing something.

[SkanerSoft]

It may be easier for you to find access to an Android phone (eg Samsung M12), and if you can fix the problem on it, it may (but not sure) fix the problem on the iPhone as well. This is just a guess.

[akien-mga]

So I think we may be looking at two problems:

1. In general octahedral compression does not work on iPhone under GLES2

That seems correct, at least for some iPhones. Might be useful to get test results from more iPhone models to confirm.

What @SkanerSoft tested so far seems to be an iPhone SE 2016 (A9 APU): https://www.gsmarena.com/apple_iphone_se-7969.php (i.e. not the current iPhone SE 2020 with A13 APU: https://www.gsmarena.com/apple_iphone_se_(2020)-10170.php)

2. There is an issue where a project being opened up which was not using octahedral compression on it's assets has broken rendering (perhaps somewhere a flag is being set which is making the renderer think octahedral is being used on these assets when it should not)

I'm not sure about that one, maybe @SkanerSoft can confirm. I think the affected geometry might have all been imported after octahedral compression was added to the engine and enabled by default. The main issue @SkanerSoft is having is that since their workflow involves converting the geometry into Godot's own format (as opposed to using the imported .glb directly), it cannot be reimported easily and thus the only available geometry is the octahedral compressed one.

[SkanerSoft]

Please also note that in this project, the astronaut models were first imported into Godot 3.5 Beta 1, and compression also broke their rendering.

Unfortunately, I didn't know before, but it turns out to be broken on some Androids as well. And not all models break.

What I have noticed so far:

1. [Android] Compression is 100% broken for animated models (example in test.zip archive), other models are displayed normally both with and without compression.

Example https://github.com/godotengine/godot/files/7984682/test.zip

2. [iPhone SE] Some animated models break (but not all), the rest of the models are displayed broken in 90% of cases, another 10% are not displayed at all and cause two options for verification:
   • Infinite error 500
   • Game crash with access error.

Example https://github.com/godotengine/godot/files/7984788/min_project.zip

If you turn off compression, then on all devices all models (with and without animation) are displayed completely correctly and do not cause errors.

[The-O-King]

Ok one thing I can bring up right now at least is that there's another issue open on Android devices with Mali GPUs which causes issues with rendering of animated meshes, and the Samsung M12 has one of these gpus :/ - although I have not found a way to resolve it or truly confirm the driver bug yet (see this issue https://github.com/godotengine/godot/issues/54763)

[SkanerSoft]

There was a thought. Is there a way to disable "Octahedral Compression" not at the import level, but at the project settings level? So that the tuning engine can completely ignore it altogether.

Or, if the model was imported with compression, then the engine can use it ONLY with it and nothing else?

Something like "ignore Octahedral Compression" or "disable Octahedral Compression" could be added to the settings.

I guess a lot of users could import their models without being aware of this error... like me =)

[Calinou]

There was a thought. Is there a way to disable "Octahedral Compression" not at the import level, but at the project settings level?

Since Godot 3.3, you can change the import defaults for each file type in the project settings. However, new defaults will only take effect when (re)importing resources in the future. To apply the new defaults on already-imported resources, exit the editor, remove the .import/ folder and open the editor again to force all resources to be reimported.

[SkanerSoft]

@Calinou

Unfortunately, some of my assets were created over a year ago and I just don't have the files to re-import them. I'll have to recreate them, which will take me weeks... there are a lot of objects in the game.

I recommend reading the entire discussion so that I do not repeat myself.

[Calinou]

Unfortunately, some of my assets were created over a year ago and I just don't have the files to re-import them. I'll have to recreate them, which will take me weeks... there are a lot of objects in the game.

By definition, octahedral compression is a destructive operation. It's not possible to simply disable it on meshes that were already imported with octahedral compression enabled.

[SkanerSoft]

At some point, I discovered an amazing way to store game assets right in scenes, without even knowing that all my models are broken for some situations =)

I'm not upset or angry, I just feel bad that I have to spend a lot of time to revive the game for iOS =(

[Zireael07]

By definition, octahedral compression is a destructive operation. It's not possible to simply disable it on meshes that were already imported with octahedral compression enabled.

In that case, octahedral compression should default to OFF (with a big warning that it is destructive!)

[Calinou]

In that case, octahedral compression should default to OFF (with a big warning that it is destructive!)

It is only destructive if you remove your source resources, which you should never do since Godot 3.0 – it's not a supported workflow anymore. To clarify, Godot's import system does not overwrite your source resources. However, if you remove your scene resources (and still have the imported resource lingering in .import/), you can't get the source resource back without filesystem recovery tools.

[SkanerSoft]

In most cases, users are unaware of the presence of compression at all. For example, me =) I found out about this a year later, when the game refused to work on iOS. At this point, I have successfully imported meshes and saved them into scenes. I would remove this option from the default by making it disabled. Too unstable. Let it be included by those who understand what they are doing.

[Calinou]

In most cases, users are unaware of the presence of compression at all. For example, me =) I found out about this a year later, when the game refused to work on iOS. At this point, I have successfully imported meshes and saved them into scenes. I would remove this option from the default by making it disabled. Too unstable. Let it be included by those who understand what they are doing.

Considering the benefits of octahedral compression have yet to be proven on real world Godot projects[^1], I'd vouch for removing it entirely rather than disabling it by default in 3.5. However, this means contributors would have wasted a lot of time working on https://github.com/godotengine/godot/pull/46800 and follow-up PRs…

In this case, loading octahedral compressed meshes should be supported (for existing 3.4 projects), but importing code would be removed.

That said, octahedral compression wasn't ported to master yet. Maybe it has more benefits there, and perhaps Vulkan-supporting devices are in a better situation to deal with meshes that use octahedral compression.

[^1]: Octahedral compression usually does not improve performance, but it can reduce battery usage on mobile devices. However, I don't think this hasn't been benchmarked yet in Godot.

[SkanerSoft]

Finally, I will add the text of the errors, maybe this will help in solving them.

ERROR: Condition "!p_I" is true. Returned: false
   at: erase (./core/list.h:149) - Condition "!p_I" is true. Returned: false
2022-02-03 21:54:48.174597+0300 Bunker[1198:389914] DrawView: 500 error
2022-02-03 21:54:48.178866+0300 Bunker[1198:390217] Execution of the command buffer was aborted due to an error during execution. Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)
2022-02-03 21:54:48.181495+0300 Bunker[1198:390217] Execution of the command buffer was aborted due to an error during execution. Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)
2022-02-03 21:54:48.181985+0300 Bunker[1198:390217] GLDRendererMetal command buffer completion error: Error Domain=MTLCommandBufferErrorDomain Code=2 "Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)" UserInfo={NSLocalizedDescription=Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)}
2022-02-03 21:54:48.190908+0300 Bunker[1198:389914] DrawView: 500 error
2022-02-03 21:54:48.194638+0300 Bunker[1198:390217] Execution of the command buffer was aborted due to an error during execution. Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)
2022-02-03 21:54:48.194859+0300 Bunker[1198:390217] Execution of the command buffer was aborted due to an error during execution. Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)
2022-02-03 21:54:48.195145+0300 Bunker[1198:390217] GLDRendererMetal command buffer completion error: Error Domain=MTLCommandBufferErrorDomain Code=2 "Caused GPU Hang Error

[The-O-King]

Apologies for the delay, I have been learning how to use xcode/develop on mac/ios for the past day or so haha (thanks to my friend for letting me use their apple devices to dig into this!)

Ok so some progress - I think I found the issue causing all of those DrawView: 500 errors - it's actually not the octahedral compression (surprise!); in my implementation of split stream vertex buffers, I seem to have missed setting the uses_half_float flag in rasterizer_storage_gles2.cpp when checking the format for compressed vertex positions - this is causing an invalid enum and resulting in the messed up rendering seen in the first

As for the rendering artifacts seen on the character models in the minimal scene, those may be caused by octahedral, but I have not been able to reproduce that on the iphone that I have access to (iPhone 13 pro) - I am curious though if anything changes in the rendering after the half_float fix is merged in - I'll see if I can dig into this aspect of it though and see if I can reproduce

and just as a quick response to the usefulness of octahedral compression - while I recognize the performance and battery life claims have not necessarily actualized in real world projects (just the benchmarks I've made), I would like to also point out that there is also a large visual quality improvement in using octahedral compression (almost ground truth level quality for the same cost as the old compression technique) so there is value there too; I'm a bit confused how loading octahedral compressed meshes could work if you couldn't import your meshes as octahedral compressed in godot to create them in the first place (there are no 3D modelling packages I'm aware of that export octahedral compressed meshes)

[SkanerSoft]

@The-O-King

This is good news! I'm glad there's progress! I can run tests if you provide any interim builds with fixes!

As for rendering artifacts (characters with animation), you can try to reproduce this on Android, they are also observed on it.

From myself, I can conduct tests on both iPhone (A9) and Samsung (Mali).

[akien-mga]

Do you still reproduce the same issue in 3.5 beta 4 or later? There were various fixes to octahedral compression in the past few betas.