[3.3/3.4b] «2D Pixel» preset glitch in 3D

[alchem1ster]

Godot version

both 3.3.4 stable and 3.4 beta 6

System information

Windows 10, GLES3, RTX 2070 Super (472.12)

Issue description

When loading some voxel textures into Godot and applying the "2D Pixel" import preset, texture artefacts occur. It does not depend on the type of model: dae, obj or fbx.

There are no such problems when loading in Blender etc.

Blender:

Godot:

Steps to reproduce

Import throne sample model from ZIP to Godot project. Apply "2D Pixel" preset to PNG texture, reimport it and apply to model.

Minimal reproduction project

throne.zip Throne_sample.zip

[Calinou]

@alchem1ster Please upload a minimal reproduction project to make this easier to troubleshoot.

The project you uploaded only contains the Collada file and its texture, not a complete Godot project.

[alchem1ster]

Added project sample Throne_sample.zip

[Calinou]

I can confirm this on commit f6784e18d.

The wireframe view looks fine:

Changing the texture's compression mode to Lossy will reveal that UV mapping is done in a weird way:

I'd try using glTF 2.0 over Collada and see if the issue persists. This looks like a 3D import/export issue to me rather than an issue with the texture itself. The texture itself looks like it's correctly imported:

[alchem1ster]

@Calinou

I'd try using glTF 2.0

If you mean gltf+bin+textures separately, the problem persists

[Calinou]

If you mean gltf+bin+textures separately, the problem persists

Try triangulating the model before exporting it from the 3D software you're using. This is always more reliable than letting the 3D importer perform the triangulation. In Blender, you can do this by adding a Triangulate modifier and enabling Apply Modifiers in the export dialog. Some exporters such as Blender's OBJ exporter also feature a Triangulate Faces option, but I recommend using a triangulate modifier and applying it on export instead as this lets you preview the triangulation.

This advice isn't exclusive to Godot. It's common practice when working with 3D software such as a Blender -> Substance Painter workflow as well.

[alchem1ster]

Of course. I always do Triangulation and Recalculate Normals. That doesn't seem to be the problem

p.s. Anyway, for some reason the same model is displayed correctly in Blender

[scurest]

This is caused by UV compression. The compressed UVs are not accurate enough in this case. If you untick Meshes>Compress in the Import pane and reimport, it's fixed. I believe Godot uses float16s for UVs? You get a similar (though not identical) effect if you convert all UVs to float16s and back in Blender.

Click to see picture


---

Aside:

Try triangulating the model before exporting it from the 3D software you're using. This is always more reliable than letting the 3D importer perform the triangulation.

For the Blender glTF exporter, this is not true, you should always let the exporter triangulate for you. It will export the triangulation that Blender actually draws. You should not apply a triangulate modifier, it will not give you the right triangulation.

[alchem1ster]

@scurest

If you untick Meshes>Compress in the Import pane and reimport, it's fixed

Nope :/

Godot screenshot


[scurest]

After hitting reimport, double click on untitled.gltf and do "New Inherited" again. Works for me on 3.3.4 stable.

[alchem1ster]

Confirmed, but..

3.3.4 stable:

• Uncheck 'Compress', Reimport - nothing change. Remove object from scene, add new one - all correct, no more artifacts. Save project.

3.4 b6:

• Open this project. No artifacts. Reimport - all is good. Remove object from scene, add new one - again glitches!

3.3.4 stable:

• Open project.... and: ERROR: mesh_add_surface: Condition "array.size() != array_size" is true. At: drivers/gles3/rasterizer_storage_gles3.cpp:3728 ERROR: mesh_surface_set_material: Index p_surface = 0 is out of bounds (mesh->surfaces.size() = 0). At: drivers/gles3/rasterizer_storage_gles3.cpp:4038 ERROR: instance_set_surface_material: Index p_surface = 0 is out of bounds (instance->materials.size() = 0). At: servers/visual/visual_server_scene.cpp:764 ERROR: mesh_add_surface: Condition "array.size() != array_size" is true. At: drivers/gles3/rasterizer_storage_gles3.cpp:3728 ERROR: mesh_surface_set_material: Index p_surface = 0 is out of bounds (mesh->surfaces.size() = 0). At: drivers/gles3/rasterizer_storage_gles3.cpp:4038 ERROR: instance_set_surface_material: Index p_surface = 0 is out of bounds (instance->materials.size() = 0). At: servers/visual/visual_server_scene.cpp:764 ERROR: instance_set_surface_material: Index p_surface = 0 is out of bounds (instance->materials.size() = 0). At: servers/visual/visual_server_scene.cpp:764 ERROR: mesh_surface_get_primitive_type: Index p_surface = 0 is out of bounds (mesh->surfaces.size() = 0). At: drivers/gles3/rasterizer_storage_gles3.cpp:4160

So, if doing Reimport in 3.3.4 stable all seems to be good. But something wrong in 3.4.

[Calinou]

This is likely a regression from https://github.com/godotengine/godot/pull/46800. I think there's an option to disable mesh compression in the 3D scene's import options.

[alchem1ster]

But why doesn't it fix objects that are already in the scene after pressing the Reimport button? To remove the artefacts I need to either remove the object from the scene and add it again, or create a child inherited scene for it. But what if I have hundreds of objects in the GridMap?

[akien-mga]

This is likely a regression from #46800. I think there's an option to disable mesh compression in the 3D scene's import options.

CC @The-O-King

[lyuma]

I saw this PR wasn't merged: https://github.com/godotengine/godot/pull/48625

Is the special import setting still needed? or was that PR obsoleted by something else?

[The-O-King]

So yea this has to do with the UV coordinate compression

I updated PR #48625 to resolve merge conflicts as I think it would a valuable feature to have, being able to more granularly control what attributes are/are not compressed - so that in this case you could enable compression on everything except UV coordinates vs having to either disable ALL compression because one attribute didn't play nice with compression

When I was testing things I was able to import/reimport the .dae file with/without UV compression and that fixed the issues seen here

As for the behavior of Godot when reimporting - I think that's been Godot's behavior for this type of thing for a while

1. If you imported an asset as a scene (lets call this scene A) and then merged a mesh from the asset's scene into a new scene (lets call this scene B), the mesh in the new scene (B) is essentially detached from the scene created directly from the asset (A), so reimporting will not effect it at all, it's stuck using whatever the import setting was at the time of merging

2. if you import an asset as a scene (lets call it scene A) and then use that scene as a node in a new scene (lets call this one scene B), reimporting WILL affect the node in scene B but only after opening and closing the scene

Is my understanding of the scene behavior correct here?

[akien-mga]

Tested and the issue is still reproducible in 3.5 beta 5.

As discussed above by @The-O-King, it's related to UV coordinate compression. I found that disabling Meshes > Compress > TexUV and reimporting the DAE is sufficient to solve this issue:

@The-O-King Can/should we consider that this is working as intended and that this is a kind of mesh where the user needs to disable compression explicitly? Or can the importer be clever about it and automatically disable compression when it detects cases like this where it might be problematic?

[The-O-King]

So right now, yes I believe everything is working as intended, as this is just a precision issue with compression the UV coordinates to an insufficient precision level for the texture coordinates used by this mesh

As for whether or not we can detect this automatically and disable as needed, that's a good question; my initial instinct would be that we would check the delta between what the compressed UV coordinates is and the ground truth UV coordinate is during import, and if that delta is larger than some threshold; we print a warning to the log letting the user know that it might be good to try reimporting this mesh without compression if they see any rendering artifacts (or perhaps we can restart the import automatically, not sure what would be preferred)

I can investigate a feature like this if that sounds like a good solution to this problem!