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

Good afternoon! The problem has now been fixed!

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)

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.

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

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.

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)

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

The smallest project.

Bunker_21.zip

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.