IanC, @Adam_Carp, @Yusuf, @Andrea,
I was able to load the files into Rhino and found that there are indeed duplicate vertices. They occur as pairs. The problem is that there are different texture coordinates on the two vertices in a pair. Is this actually functional, that is, are both textures used to make the 3D model or is one just dropped? The number of duplicate vertices is 9.3% for this file. Note this is for the model with 6 independent meshes, one for each “material” file; this is the way it appears in Rhino when imported with textures. If the meshes were merged, then there could be fewer vertices but his would not work with the textures. See more about this below.
A much bigger inefficiency in the .obj file is that the face definition uses 6 values, 3 for the vertices and 3 for the texture coordinates. In the .obj file generated by DroneDeploy, the indexing for the vertices and texture coordinates are separate. But if you think about it, there are the same number of vertices and texture coordinates. So by simply re-ordering the texture coordinate entries and re-numbering the texture coordinate indices, the two sets of indices can be made identical. This means that only 3 values are needed in the face definition, one for each vertex. To visualize this, here is a face section of the DroneDepoly scene_mesh_textured.obj file that was imported into Rhino (the number format is 3 groups of: vertex_index/texture_coordinate_index):
f 21757/26842 21154/27789 21309/27665
f 21757/26842 21309/27665 21345/27650
f 21430/27813 21342/27814 21749/27815
f 20579/27816 20368/27817 21429/27818
while here is a face section of the file Rhino generated when exporting this model (notice that the vertex indices and texture coordinate indices are the same):
f 270474/270474 269428/269428 269454/269454
f 204798/204798 205584/205584 218131/218131
f 205330/205330 219452/219452 219455/219455
f 219399/219399 219338/219338 219030/219030
When imported into Rhino, both of these files look the same. This is the DroneDeploy .obj file after importing:
And this is the Rhino file imported after being exported:
So I give Rhino a high mark for doing this better. But I also give it a low mark for not removing the duplicates. However, this may be the fault of the .obj file format; it may not include an option for defaulting the texture coordinate index to the vertex index.
If this close to 100% overhead in the face definitions was removed, the .obj file would drop in size by about 35%. If the duplicate texture coordinate information is not useful, then the duplicate vertices could be removed, saving another 9.3%. So there is a potential for over 40% reduction in the file size. But achieving this may require an enhancement to the .obj file format.
If the current DroneDeploy export size limit for .obj files is 128 MB, then with a 40% file size reduction this would enable what is currently a 213 MB file to be exported (with a 128 MB file size). Your mesh has about 0.524M faces in a 37 MB .obj file. This could be increased to about 3M faces with this improvement. I need meshes with about 5M faces for the precision agriculture work I am doing with Kevin. Currently we have to generate these outside of DD. With this improvement, it might be possible to move the work back to DD.
This was a surprise to me. I thought there would be many more duplicate vertices and no savings possible in the face definitions. It turns out the reverse is true.
Typically I do not import textures into Rhino as I care about the quantitative data in .obj file, not its appearance. In this case there is only 1 mesh and many more duplicate vertices, 24% for this file. If I cleanup the model and export it to a .obj file, the file size is only 20.5MB vs 37.7MB for the original scene_mesh_textured.obj file. This is a 46% saving in the file size.
I am still looking into some more options and if any of these work out, I will report them here.