OBJ Importer: Vertex Colors Lose Alignment In At Least 2 Situations #117367

New Issue

L.Spiro · 2024-01-20T19:16:43+01:00

L.Spiro commented

2024-01-20 19:16:43 +01:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: GeForce RTX 3050 Ti Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 462.62

Blender Version
Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: 9be62e85b727
Worked: (newest version of Blender that worked as expected)

Short description of error
I have found that Blender likes vertex colors to simply be an extension of the v line in .OBJ files, so I insert vertex colors into my .OBJ file by making a 6-element v instead of a 3- or 4- element v.
IE:

    v -291.437500 19.875000 -420.062500 0.749020 0.874510 0.121569
    v -305.187500 16.000000 -362.187500 0.749020 0.874510 0.121569
    v -247.937500 18.000000 -362.187500 1.000000 1.000000 1.000000
…

By definition this means that vertex colors are strongly associated with vertices. IE it is not possible to have the correct vertices but incorrect vertex colors. And yet there are at least 2 ways this happens in Blender 4.0: Referencing only a section of the v/vt/vn tables and by using o.

This image shows the correct result on the left and the misaligned vertex colors on the right:

In both files, the v/vt/vn tables are exactly the same, and all of the f (face) values are exactly the same, but in the right image there is an o at the very start of the face data (which, alone, does not cause the issue) and a 2nd o object starting at the first transparency-enabled face at the end of the file (I have put all the non-opaque faces at the end of the face data in both cases, it’s just that in the 2nd example they are in their own o object).

When the files are identical except for the addition of 2 o [name] lines, there should be no reason for vertex colors to suddenly become misaligned.

The 2nd way that this exact same error can occur is by simply chopping off faces from the end of the file.
In this case, I produce the erroneous result by going to roughly the 3,270th face and then simply removing all of the following faces in a text editor. The file remains valid, and no other data has been modified, it’s just that there are fewer faces, thus also some of the v/vt/vn values are no longer referenced.

By doing this, I get the following result, which is basically just a section of the incorrect right result above:

The fact that some of the v/vt/vn values have become unreferenced should not cause a problem for the loader, and it is even more baffling because the vertex colors are defined on the same lines as their associated vertex positions, making it normally impossible for the vertex positions to be correct but the vertex colors to be wrong.

Exact steps for others to reproduce the error
1: Create a reasonably complex object in Blender with colored vertices. In my above example, my model has 1051 v (with 6 floating-point values each to include vertex colors), 1261 vt, 959 vn, and 1216 f.
2: Export to .OBJ.
3: Load it again to confirm it looks fine.
4: Edit the .OBJ file in a text editor. Pick a face anywhere from maybe 30% down the file or later and simply delete all faces after that. In my example above, I started getting bad vertex colors when I started deleting faces that indexed into the 240-270 range in my tables, though I have created other examples that look correct for many more vertices than this before going AWOL.
5: Save and load and observe incorrect vertex coloring.

L. Spiro

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: GeForce RTX 3050 Ti Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 462.62 **Blender Version** Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: `9be62e85b727` Worked: (newest version of Blender that worked as expected) **Short description of error** I have found that Blender likes vertex colors to simply be an extension of the `v` line in .OBJ files, so I insert vertex colors into my .OBJ file by making a 6-element `v` instead of a 3- or 4- element `v`. IE: ``` v -291.437500 19.875000 -420.062500 0.749020 0.874510 0.121569 v -305.187500 16.000000 -362.187500 0.749020 0.874510 0.121569 v -247.937500 18.000000 -362.187500 1.000000 1.000000 1.000000 … ``` By definition this means that vertex colors are strongly associated with vertices. IE it is not possible to have the correct vertices but incorrect vertex colors. And yet there are at least 2 ways this happens in Blender 4.0: Referencing only a section of the v/vt/vn tables and by using `o`. This image shows the correct result on the left and the misaligned vertex colors on the right: ![image](/attachments/ddb9f32f-cc64-4345-b747-92de5688d4c2) In both files, the `v/vt/vn` tables are exactly the same, and all of the `f` (face) values are exactly the same, but in the right image there is an `o` at the very start of the face data (which, alone, does not cause the issue) and a 2nd `o` object starting at the first transparency-enabled face at the end of the file (I have put all the non-opaque faces at the end of the face data in both cases, it’s just that in the 2nd example they are in their own `o` object). When the files are identical except for the addition of 2 `o [name]` lines, there should be no reason for vertex colors to suddenly become misaligned. The 2nd way that this exact same error can occur is by simply chopping off faces from the end of the file. In this case, I produce the erroneous result by going to roughly the 3,270th face and then simply removing all of the following faces in a text editor. The file remains valid, and no other data has been modified, it’s just that there are fewer faces, thus also some of the `v/vt/vn` values are no longer referenced. By doing this, I get the following result, which is basically just a section of the incorrect right result above: ![image](/attachments/542767cb-b663-4682-9edc-c7018c53ae82) The fact that some of the `v/vt/vn` values have become unreferenced should not cause a problem for the loader, and it is even more baffling because the vertex colors are defined on the same lines as their associated vertex positions, making it normally impossible for the vertex positions to be correct but the vertex colors to be wrong. **Exact steps for others to reproduce the error** 1: Create a reasonably complex object in Blender with colored vertices. In my above example, my model has 1051 `v` (with 6 floating-point values each to include vertex colors), 1261 `vt`, 959 `vn`, and 1216 `f`. 2: Export to .OBJ. 3: Load it again to confirm it looks fine. 4: Edit the .OBJ file in a text editor. Pick a face anywhere from maybe 30% down the file or later and simply delete all faces after that. In my example above, I started getting bad vertex colors when I started deleting faces that indexed into the 240-270 range in my tables, though I have created other examples that look correct for many more vertices than this before going AWOL. 5: Save and load and observe incorrect vertex coloring. L. Spiro

image.png

470 KiB

image.png

109 KiB

L.Spiro added the

labels 2024-01-20 19:16:44 +01:00

Scurest commented

2024-01-20 19:29:45 +01:00

Can you attach an OBJ file for testing?

Scurest commented

2024-01-20 21:00:09 +01:00

Nevermind, I managed to repro the case of inserting an o line. I've attached a Test.obj. If o obj is inserted on line 796, the vertex colors are broken. If it is inserted on line 797 instead though, it doesn't break.

Iss117367.zip

     Test.obj        Test-Line796-Broken.obj  Test-Line797-Working.obj
     -------------   -----------------------  ------------------------
794  f 397 399 400   f 397 399 400            f 397 399 400
795  f 401 402 403   f 401 402 403            f 401 402 403
796  f 401 403 404   o Test2                  f 401 403 404
797  f 405 406 407   f 401 403 404            o Test2
798  f 405 407 408   f 405 406 407            f 405 406 407

Nevermind, I managed to repro the case of inserting an `o` line. I've attached a Test.obj. If `o obj` is inserted on line 796, the vertex colors are broken. If it is inserted on line 797 instead though, it doesn't break. [Iss117367.zip](/attachments/c498f313-82c8-4dc8-b348-d018ec072521) ``` Test.obj Test-Line796-Broken.obj Test-Line797-Working.obj ------------- ----------------------- ------------------------ 794 f 397 399 400 f 397 399 400 f 397 399 400 795 f 401 402 403 f 401 402 403 f 401 402 403 796 f 401 403 404 o Test2 f 401 403 404 797 f 405 406 407 f 401 403 404 o Test2 798 f 405 407 408 f 405 406 407 f 405 406 407 ``` ![ObjVertexColorIssue.png](/attachments/1be9520e-bcb8-409a-b7c8-f0d7bd1564e1)

ObjVertexColorIssue.png

204 KiB

Iss117367.zip

15 KiB

Scurest commented

2024-01-20 21:37:07 +01:00

Simpler example: Take this OBJ file

v -0.004936 0.000000 1.013093 1.0000 0.4235 0.0000
v 1.995063 0.000000 1.013093 1.0000 0.8470 0.0000
v -0.004936 0.000000 -0.986907 1.0000 0.4235 0.0000
v 1.995063 0.000000 -0.986907 1.0000 0.8470 0.0000
v -1.947056 0.000000 1.013093 1.0000 0.0039 0.2118
v -1.947056 0.000000 -0.986907 1.0000 0.0000 0.2118
s 0
o Plane
f 1 2 4 3
f 1 3 6 5

If you insert o Plane2 between the f lines, it breaks.

Simpler example: Take this OBJ file ``` v -0.004936 0.000000 1.013093 1.0000 0.4235 0.0000 v 1.995063 0.000000 1.013093 1.0000 0.8470 0.0000 v -0.004936 0.000000 -0.986907 1.0000 0.4235 0.0000 v 1.995063 0.000000 -0.986907 1.0000 0.8470 0.0000 v -1.947056 0.000000 1.013093 1.0000 0.0039 0.2118 v -1.947056 0.000000 -0.986907 1.0000 0.0000 0.2118 s 0 o Plane f 1 2 4 3 f 1 3 6 5 ``` If you insert `o Plane2` between the f lines, it breaks. ![VertexColorIssue2.png](/attachments/e0fcebc8-31ad-4f20-884f-a91b1d888c23)

VertexColorIssue2.png

31 KiB

Scurest commented

2024-01-21 19:58:57 +01:00

Just looking at MeshFromGeometry::create_colors, I think it assumes the Blender object vertex index (local vertex index) corresponds to a contiguous range of vertices in the OBJ file (global vertex index), which isn't necessarily true. It seems like it should probably do something like

for each global_vi in mesh_geometry_.vertices_ {
   let local_vi = mesh_geometry_.global_to_local_vertices_[global_vi]
   colors[local_vi] = get_color_at_global_vertex_index(global_vi)
}

(It also apparently currently requires that the whole range of OBJ vertices from the first used one to the last used one have vertex colors (ie everything sits within a single VertexColorsBlock), even if some of the vertices in that range are never referenced by the object. But that's a different issue.)

@aras_p

Just looking at [MeshFromGeometry::create_colors](https://projects.blender.org/blender/blender/src/commit/6a9d2212e43ee0a49bbf32c32bb5531a40a8f7ee/source/blender/io/wavefront_obj/importer/obj_import_mesh.cc#L394-L420), I think it assumes the Blender object vertex index (local vertex index) corresponds to a contiguous range of vertices in the OBJ file (global vertex index), which isn't necessarily true. It seems like it should probably do something like ``` for each global_vi in mesh_geometry_.vertices_ { let local_vi = mesh_geometry_.global_to_local_vertices_[global_vi] colors[local_vi] = get_color_at_global_vertex_index(global_vi) } ``` (It also apparently currently requires that the whole range of OBJ vertices from the first used one to the last used one have vertex colors (ie everything sits within a single VertexColorsBlock), even if some of the vertices in that range are never referenced by the object. But that's a different issue.) @aras_p

Pratik Borhade added

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

OBJ Importer: Vertex Colors Lose Alignment In At Least 2 Situations #117367