Anomalies in obj exports from dronedeploy

General Discussion
1

hey…I’ve run into a problem and I’m not sure why. I need to keep my obj exports under 200mb so i can upload to sketchfab on my plan. usually i acheive this by keeping the data that goes into a map at around 750mb (give or take 150 photos at 12mp) i have two maps, one at 730mb (134photos) the other at 750mb (141 photos) the first gives me an obj export from drone deploy at about 125mb the second gave me an obj export of 385mb, more than a 200mb overall difference for 7 photos! what happened? this is really frustrating me

3

Hi @punkie,

Thanks for swinging by the DroneDeploy Forum. To answer your question in regards the size of the OBJ file format, the size of the final output does not only depend on the number of images uploaded. It also depends on the extension of the mapped area, the complexity of the site mapped, the quality of the 3D model itself, which is directly related to the version of the stitching algorithm used to create the map, etc.

So, there are several factors that could affect the size of your final output. In case you want us to analyze the maps that you are referencing, please do let us know the names of the maps in question.

Happy mapping!
Andrea

4

hi Andrea,

heres one map which is 120 images, one i expand the files on my computer for the obj they come out to 385mb,

https://www.dronedeploy.com/app2/data/5b3c1cd4382d536ecd146a16

whereas this one is 134 images,

https://www.dronedeploy.com/app2/data/5b2d96eb3bbd52cefb9e6db6

of the same piece of land but over a smaller area (other map was taken higher up) the obj files for this come out at 125mb. I cant imagine why the map with less images is such a larger file? I’ve done maps over larger areas before with more images (of similar terrain) come out at under 200mb, which is important to me for sharing maps on sketchfab. Is there somehow I can have more control over the end obj size?

duncan

6

Hi @punkie,

Thanks for providing this information. I went ahead and took a look at your maps and it seems that the issue here is that both maps were processed with different versions of our stitching algorithm. To correct this discrepancy I could go ahead and reprocess your map a825f8ae78_D24537C558OPENPIPELINE (with 120 images) to see if that helps to create a less heavy OBJ export.

Please let me know if you would like me to try that out on my end.

Cheers,
Andrea

7

Thanks Andrea,

That would be good, is their any way as a user to have control over which algorithm is used?

8

Hi @punkie,

Currently, all maps should be processed with the same algorithm. The version in the past have changed, but we are now working with the same algorithm across all the maps. So, if you have any other maps that, in the past, has caused the same OBJ file issue, please share with me the maps in question and I can reprocess them on my end.

As for your map a825f8ae78_D24537C558OPENPIPELINE (with 120 images), I have restarted the processing of your map. You should see the “Processing” status on your dashboard shortly. I hope this helps.

Best,
Andrea

9

Hi Andrea, I cant find the map that you reprocessed for me, but I had already tried to upload a second time, and the map that produced was much more a much more usable size for me, obj was 148mb unpacked. how long ago has the algorithm become standardized? the other upload of this map was not that long ago… around the 30th june

11

Hi @punkie,

I’m happy to hear that re-uploading the images to a new map helped to correct the OBJ export size. You can access your reprocessed map by clicking in the next hyperlink: a825f8ae78_D24537C558OPENPIPELINE
This standardization is relatively recent and it was rolled out progressively so maybe it was affecting some of your maps, but not all of them.

Hope this resolves your question. Happy mapping!
Andrea