GLTF export invalid in 3.4 beta 2

[MrJoshBowman]

Godot version

3.4 Beta 2 Official

System information

Macbook Pro 2019 16", AMD Radeon Pro 5500M

Issue description

Exporting a GLTF/GLB file in 3.4 Beta 2 causes errors in PowerPoint and Windows 3D Viewer.

I tested the same exact code in GDv4.0 and it exports just fine from GD4.0

Steps to reproduce

Open the minimal reproduction.
Run it.
Let it export the GLB file.
Try importing the file into PowerPoint or Windows 3D Viewer

Minimal reproduction project

20_GLTF_Export_GD3.4Beta2.zip

[lyuma]

Progress update.
I'm looking through the validation errors:

GLB_CHUNK_LENGTH_UNALIGNED	Length of 0x004e4942 chunk is not aligned to 4-byte boundaries.	--

<- should be an easy fix.

EMPTY_ENTITY	Entity cannot be empty.	/accessors/0/min

<- the line to assign accessor->min = min was missing, should be fixable

MESH_PRIMITIVE_POSITION_ACCESSOR_WITHOUT_BOUNDS	accessor.min and accessor.max must be defined for POSITION attribute accessor.	/meshes/0/primitives/0/attributes/POSITION

<- Same error as above caused by empty "min":[] field.

Now this is where things start getting strange:

ACCESSOR_VECTOR3_NON_UNIT	Vector3 at accessor indices 0..2 is not of unit length: 0.9921572334828104.	/meshes/0/primitives/0/attributes/TANGENT
ACCESSOR_INVALID_SIGN	Vector3 with sign at accessor indices 0..3 has invalid w component: 0.9921259880065918. Must be 1.0 or -1.0.	/meshes/0/primitives/0/attributes/TANGENT

<- The array[Mesh::ARRAY_TANGENT] seems to be vector3 and missing the w component, despite the length being a multiple of 4 (e.g. it's an array of size 16, and the first 12 values are correct)

TANGENT: [0.99213, 0.00000, -0.00787, 0.99213]
TANGENT: [0.00000, -0.00787, 0.99213, 0.00000]
TANGENT: [-0.00787, 0.99213, 0.00000, -0.00787]
TANGENT: [0.00000, 88.00000, 88.00000, 0.00000]

Digging into VisualServer::_get_array_from_surface I see the attached project is hitting the ARRAY_FLAG_USE_OCTAHEDRAL_COMPRESSION case.
This looks to be a regression introduced by PR #46800 (d274284) in that when compression is in use, querying ARRAY_TANGENT seems to only return three components per tangent and neglects the w component:

https://github.com/godotengine/godot/pull/46800/files#diff-833822f7ca153a64d1cd65f155a808a571f5c2b6149f5bcecd8be66c56d3ce63R1492-R1515 (you must scroll to visual_server.cpp and click 'Load Full Diff' for this link anchor to work)

That data is then passed to the export, which attempts to export these corrupt tangents. I'm going to go ping @The-O-King to see if they have ideas how to reconstruct the w components in VisualServer when ARRAY_TANGENT is requested.

I haven't yet learned which (if any) of these are making the resulting glTF files unreadable in windows 3D Viewer, but fixing these is a good first step.

[The-O-King]

@lyuma you are right there was a bug in the implementation that you pointed out where I should be multiplying j by 4 rather than 3 in order to decode the tangent vector, and the sign of the tangent vector should already by taken into account, I just wasn't writing into the vector properly!

Here's a PR with an initial fix for it #51258

[MrJoshBowman]

thanks @The-O-King, I've just downloaded and built the latest 3.x branch and still finding that the export bug is still occurring, hopefully your fix has made this another step closer to fixed :)

[lyuma]

Yeah awesome to see the fix to the octahedral compression in. that should cut down drastically on the validation errors.

I'll be looking into this issue with fire next week along with issue 51292 and other 3.4 gltf bugs.

[MrJoshBowman]

I completely understand there are many competing priorities across the different aspects of Godot development currently underway. I've reached a point in my own development however where I need the ability to export GLTF files out to be able to continue on. I wish I understood the C backend to be able to help out but my coding knowledge is limited to GDScript.

If anyone is able to put aside some time to see where this bug is at and potentially figure out a fixed I'd be so grateful.

[fire]

Need to verify

[fire]

I tested more files and the gltf validator seems to be good.

[MrJoshBowman]

Hi @fire , I'm just exporting models using the gdScript, and no textures are coming out of Godot with the .glb file. I can open the file in Blender and it only has the geometry. I went back to 3.4 beta 1 and the material is exported with the GLB.

[lyuma]

@MrJoshBowman Hi, thanks for letting us know there's still a problem.

When I test on the latest builds of Godot's 3.x branch and also on 3.4rc2 exactly using your original test project (20_GLTF_Export_GD3.4Beta2.zip), textures are properly included after exporting to .glb
Here is the generated file I created: Spatial.glb.zip

I tested it in both Windows Viewer and in https://gltf-viewer.donmccurdy.com/
I also tested it in Blender, though it seemed to not set the materials double-sided correctly. I could see the textures fine from below:

Would it be possible to list your exact reproduction steps, and confirm what test project + scene you are using to generate your GLB? Possibly open a new bug if it requires a different project and different steps to reproduce.

Thanks

[MrJoshBowman]

Ah! Thanks @lyuma for the website to check for errors, that'll help me to try and track things down on my end as well.

Here are two models from the custom app I'm building, one is exported from Beta 1 and I can see the textures (although they're glitchy, which could be an issue with how I'm creating normals) and the other is from the same app exporting from RC2 which, when viewed in Blender, doesn't include the material at all (and says the material doesn't exist using the website checker).

Both use exactly the same code to export, just from different versions of the in-development 3.x
referenceGLBs.zip

I'm using a triangle fan to create the initial ArrayMeshes
Tile_share.gd.zip

Added:
A possibility may be that it's not be picking up the material in the latest version because I'm using ArrayMeshes and placing the materials for those in Material Override, so new code might be looking for material and not material_override? 🤷🏼‍♂️ but no idea if that is actually the case.

Added 2:
Just switched back to the none triangle fan method of creating custom ArrayMeshes, and in latest custom 3.x compiled build, it's still saying that no material can be found in the exported model but the model exports with it's material when i tested my app in the beta 1 build again.

Added 3:
Did a somewhat successful test where i was able to export the GLB model out of my 3.4.rc2 based app, which exported a GLB of the model without its material. I then took that into Blender and reapplied the simple texture material for the meshes. I then exported that model from Blender, and was able to view it without any visual glitches in PowerPoint. So from my limited testing it seems to come down to the material not being exported properly in the latest 3.4.rc2 build.

[fire]

From your description it sounds like the override material is ignored. Will need to check.

[lyuma]

Indeed, it seems that GeometryInstance override material (the one per mesh) is being ignored, and MeshInstance material override (per-material) is also being ignored. So we should try and fix these.

Also, another issue is that an empty material list should not be exported as "materials":[] That causes a validation error and hence also breaks Windows 3D Viewer

That must have escaped testing because we tested roundtrip (import glb -> export same glb), which will always create materials in the mesh.

Thanks for bringing this to my attention.

[lyuma]

@MrJoshBowman
The fix should be committed. When Godot 3.4 rc3 is out, please check your projects and see if addresses all your issues.

If you run into any more issues with GLTF export, please open a new issue, with a reproduction project showing the problem.
Thanks for your reports!

[MrJoshBowman]

Brilliant! Thanks so much @lyuma 👍🏻👍🏻 looking forward to testing it

[MrJoshBowman]

@lyuma @fire

So I've tested the GLTF output with a standard material with some different flags on material and texture and these are the results. Taking the exported model into Blender, removing the Godot inserted material and simply re-applying a Principled BSDF with transparency and the same texture works. So there's something still a bit screwy with how Godot is applying materials to exported models out of Godot.

I got the same broken result when viewing the original Godot exported model with its Godot exported material in both Blender and PowerPoint (the above screenshot was taken in PowerPoint with the various versions of the model with material I tweaked and exported), the Blender material version on the right is the one that works.

• Transparency is all messed up
• Turning 'Filter' off on the texture doesn't appear to have any 'de-blurring' effect on the outputted material even though it de-blurs in Godot itself.
• Blender's 'Closest' option for texture display does what I would expect turning off 'Filter' to do on the Godot exported material

Here are the two models for reference:
gltf_comparison.zip

Added:

• Okay, the transparency issue seems to be related to any texture that has a transparency that isn't set to 'Alpha Scissor' needing to be the transparency option, so it would seem that any model exported with semi-transparent textures isn't going to export correctly using the SpatialMaterial currently.
• Even when i exported again, the textures are still blurry, even with 'Filter' set to zero for 'no flags'

[fire]

Godot does not handle filter modes correctly at all in import or export. Theres a bug for it. The other issues is gltf only has opaque, alpha scissors and blend. Theres a bug in transparency maybe.

[Calinou]

For the glTF filtering issue, see #45206.

[MrJoshBowman]

hmmm well it's really great that Lyuma was able to fix the GLTF export not being corrupted so that's definitely a great step forward, but the inability to set non-filtered textures still visually breaks GLTF exported models when transparencies are involved, but I can see how that is a separate issue to this so ✅✅ for being able to get the GLTF exporting models again, and onto hoping filters and alphas are able to be fixed soon!

[MrJoshBowman]

Also testing out the .gltf export and finding that the separated texture and mesh files aren't able to be imported. Many other applications create the .gltf file with embedded textures and meshes so that they're more compatible with a wider array of standard apps like PowerPoint.

[fire]

There are three modes gltf files can be:

1. gltf + bin + texture files
2. gltf and with the bin and texture files expanded into a text encoding and then saved as json
3. glb which is the same as 2 but with the bin and texture files as binary without encoding into base64.

Godot doesn't do 2.

[lyuma]

I would like it if we could move discussion onto separate issues. Everything written here is going to get lost and forgotten. (Especially, for any further discussion about transparency, it belongs in #45206.)

@MrJoshBowman @fire Does it make sense to change the default to .glb?

The embedded/separate question is not unique to glTF. most formats let you choose. For example .fbx allows both embedded and separate textures as well. Though it doesn't use a separate .bin file.