Editing OBJ Files

[SolarBarn]

IanC,
Did you multiply the number of triangles by 3 to get the number of vertices? My 3D models that are generated by Photoscan all have very close to 1/2 vertex per triangle due to 6-way sharing of each vertex (6 x 60 degrees = 360 degrees). It is not possible to have more than 1.5 vertices per face as that would imply 2-way sharing at each vertex with an angle of 180 degrees which is a degenerate, flat triangle. Your 3D model could actually contain 3X the number of faces if the vertices are duplicated. As I reported twice in the past year, DroneDeploy generates 3D models with duplicate vertices that bloat the storage size by 1.3X. So its possible to generate significantly smaller 3D models which would enable you and Michael to successfully process larger or more detailed sites.

I can remove the duplicated vertices if you send me a Google Drive link to the .obj file. I am not sure how this plays with the texture files but maybe they will still work. This could be part of the experiment: I remove the duplicates and you see if everything else stills works.

Regards,
Terry.

[IanC]

No, separate files. If I zip them, which should I use, the decimated version or not? And what’s the difference?

I’m in the process of uploading the files, will post a link shortly. The model’s not too bad I think for a first attempt. The extremities are not so good as I didn’t do any low orbit shots there.

[IanC]

Terry, here are the files:

https://mega.nz/#F!yEtzgSbb!DAPacKKKMKFogL4BiR49hw

Be very interesting to see if you can reduce the vertices and therefore the file size. If so, DD need to up their game!

[IanC]

@SolarBarn, the number of vertices/triangles are as quoted by Windows 3D viewer. I hadn’t actually spotted that the figures are exactly 3x, so yes all vertices are duplicated, perhaps around 6x. How ridiculously inefficient!

May I enquire how you manage to reduce them?

[MichaelL]

When you download from DroneDeploy it should be obj.zip which contains all of the texture files in order as well.

[MichaelL]

That is a lack of efficiency in the windows who you are. Most professional modeling programs use shared vertices. The number of points should be somewhere in the order of 35% of the number of triangles, but as the surface area gets larger the number of points increases. It varies with shape as well. A long linear project can be upwards of 50%. We can greatly reduce our vertices in Carlson Precision 3D by removing unnecessary points that are closer together than a defined threshold and creating our own OBJ.

[SolarBarn]

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.

Regards,
Terry.

[SolarBarn]

IanC,

I removed the 9.3% of duplicate vertices from the mesh but this damaged the appearance of the 3D model:

So this seems to demonstrate that having duplicate vertices with different texture coordinates is functional and improves the appearance of the textured 3D model.

This means that the maximum file size reduction for this model that I can see is about 35% by simplifying the face definition. However, this may require an enhancement to the .obj file format and DroneDeploy exporting the .obj file with duplicate texture_coordinate/vertex indices as nicely done by Rhino.

When an .obj file is downloaded from DroneDeploy it is zipped. If zipping was really smart it would recognize that the texture coordinates indices are a duplicate of the vertex indices and compress the file more. But when I compress the DroneDeploy .obj file with separate indices and the Rhino .obj file with duplicate indices the results are within 1%; 68% file size reduction for DD vs 69% for Rhino. So zipping is not very smart.

So 35% file-size reduction is possible. But someone would have to bite the bullet and get the .obj file to work for this case.

Regards,
Terry.

[SolarBarn]

Since the elimination of duplicate vertices did not pan out, there is no benefit for getting the OBJ file into Google Earth. For file export from DD and for file storage, there would be a benefit. This benefit would be quite large for applications not needing textures. In this case all the texture coordinates and their indices can be eliminated and the 24% of duplicate vertices removed, cutting the OBJ file size almost in half. This would be useful for some precision agriculture cases. DD could offer this option now as it requires no change to the OBJ file format. But to make it truly useful, more detailed models with 5-10M faces would need to be generated which takes more processing time. Probably not in the cards for now.

[SolarBarn]

IanC,

Rhino 6 handles OBJ files with 5M faces without difficulty. I have even loaded 50M face files but then I have to be patient when rotating the 3D model. A model with 5M faces is 10X the size of the one you sent me. Rhino 6 offers a free 90-day trial with full functionality. After that it can be used as a free viewer. I heavily edit the 3D models I load into Rhino 6. Have you tried it?

Your existing 3D mesh model with only 0.5M faces is not very detailed with some of the cars merged together.
Click on the picture below to see more details.

Here is a closeup of the cars in the middle where the resolution should be about as good as it going to get:

but the cars are still merging into each other. Maybe this is more due to the overlaps used than the number of faces. If you send me a link to the photos, I will create a model with 5M faces or so to see if there is an improvement.

Regards,
Terry.

[Jamespipe]

Hi all,

Thanks for the detailed analysis. I just wanted to get back to the root cause of this analysis. We currently downsample the mesh exports as historically this was required for Sketchfab support. There are two ways we limit exports right now - one is to limit exports to 6GPixels for non enterprise accounts. The second is a blanket downsample of the mesh on larger maps to allow upload to sketchfab, but this is no longer a requirement for our 3D viewer.

Could you clarify which of the above seems to be causing you a problem (or neither!)

James

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.

[SolarBarn]

James,

Thanks for your response.

Kevin and I have been struggling to gather detailed information on trees from drone photos. We have made progress. We can now characterize each of the 10,000 trees on 80-acres sites, providing information in the form of histogram plots of the tree height, canopy diameter, volume and estimated yield along with beautiful color maps showing these details. To do this we had to create a much more detailed model that what we could export from DroneDeploy. Our current successful models have 5M faces with an OBJ file size of about 250MB (around 100MB zipped) without textures and 462MB with textures. This model is generated from a 290M point cloud. I also tried 17MB face models for the 80-acres but these provide no significant additional information on the trees.

You mentioned 6GPixels as an export limit but that applies to a picture. I do not know how this translates to an OBJ file size. And I do not know if a model with 5M faces generated by DroneDeploy would contain enough useful information. We could do an experiment if you want. For myself it makes no difference as I am retired and have no commercial interest in drone data. But Kevin could benefit and I am working to help him. I have the photos for three 80-acres sites and these have all been processed thru DroneDeploy once but the results are not interesting as the trees have too low of a resolution and appear more as melted blobs with too short of a height:

As a result, the histogram plot of the tree volumes is incorrect:

The tree volumes are done just like the pile volumes you calculate in DroneDeploy, except in this case they are done 10,000 at a time using Rhino 6.

The information from analysis of the drone data can be quite useful for tracking progress when areas are replanted. Here is an example for Block 8 that shows very dramatically that the newly planted section of this block is still in its early days when it comes to yield:

This is a tile plot I created by using tiles the size of a tree site (16 x 20 feet) and coloring the tile according to the yield estimate for the site. The likely low yield is discernible but much less obvious in the textured 3D model:

The DroneDeploy results for Block 1 are sitting on my Dashboard under the name: Block 1, Sept 1 2018. Kevin processed this block originally and gave me a link to the results. The links to the photos seem to be in my copy. Do you want to try re-processing them to generate a more detailed 3D model with around 5M faces and arrange for us to download it somehow? You do not need to include textures in the file for download as these are of no benefit for our precision agriculture application. Including them will nearly double the size of the OBJ file, likely pushing it close to 500MB. Also any duplicate vertices should be eliminated as they just increase the file size without providing any additional information.

I have plenty of time to help you improve DroneDeploy for this application. Just let me know what I can do.

Regards,
Terry.

[Jamespipe]

Hi Terry! Sorry i didn’t get back to you faster.

We’re certainly downsampling the output. I’m curious why you are not using the Point Cloud for this analysis. We are working on tree counting right now, using machine learning methods. I wouldn’t be able to produce a biomass estimate, just a count of trees in the orchard. I’m going to run all of your and Kevin’s “block” maps through that system to see what the results are like.

Here’s a gif of what we achieved for date palms:

One thing to note - when processing those maps I think you’re using our “terrain” mode. This produces a lower resolution point cloud and mesh than the “Structures” mode, which is designed for building modelling with overhanging structures. Also if you processed any maps on a free account, these are processed at a far lower resolution.

James

[SolarBarn]

I do not know if Rhino can do the type of analysis on a pointclouds like what I am doing with a mesh. I will look into this. I do not know if it would be as fast. It takes my code less than a minute to characterize the 10,000 trees on an 80-acres site. This includes (1) generation of a DTM for the site which enables tree-height measurement relative to the local ground level (2) automatic identification of the X&Y tree pitches using autocorrelation (3) location of the offset of the larger male trees using autocorrelation (4) construction of a bin for each tree site (4) identifying empty tree sites (4) trimming the mesh to the edges of the active tree sites, (5) counting all female and male trees (6) extracting height, diameter, volume and estimated yield for each tree (7) creating 10 histogram plots and (8) data for display of 10 tile maps. For this to work well, 5M faces in the 3D mesh model seems to be sufficient for an 80-acres site. The only user input is the OBJ file name. With this, the import of the OBJ file thru to the display of the histogram summary is done automatically with only 1 user input to outline the area of interest (like you show above).

I look forward to examining what you can generate by reprocessing Kevin’s photos. Again, for my immediate analysis, it needs to be 1 mesh with no texture files. Or it could be 1 mesh with texture files and I will just ignore the textures (but your OBJ file will be about 2X larger).

I can see that your tree counting mostly works with only a few escapes. But for Kevin’s application we are dealing with an orchard on a surveyed grid which improves results.The only debate on the counting results is what height or volume you set for the threshold of an occupied tree site. The count is nice to know but the quantitative information is much more interesting. Initially Kevin asked me only to help with the count. But then I showed him how we can extract data that is many times more valuable. If you are considering buying an orchard, let us analyze it first so you can avoid buying a lemon. The data we can provide is very informative. The key to extracting this information is an accurate DTM for the site. This can be easily built if there is ground showing around the trees. I may be able to analyze the example you show above as it seems like the trees may be on a grid.

Regards,
Terry.

[IanC]

Thanks Terry, would have been interesting but I no longer have the photos.

[SolarBarn]

@Jamespipe,

It has been 3 weeks since I last heard from you. Outstanding items:

1. Counting results for Block 1 or other blocks using DroneDeploy technology
2. 3D mesh model with 5M faces for Block1 for analysis with our precision agriculture app to see if the 10,000 trees have sufficient detail.

Regards,
Terry.

[Jamespipe]

Hi Terry - will drop you some notes in a private message.

[toucha_toucha]

I think you’re using our “terrain” mode. This produces a lower resolution point cloud and mesh than the “Structures” mode, which is designed for building modelling with overhanging structures.