Where is the file textured.obj?

Hi @Charles_Trindade, during processing we downsample the final mesh to 4M faces if it is larger than that, mainly so that the 3D model loads quickly in the viewer. This limit should only come into effect for large maps (most maps have < 4M faces). Previously we had been saving the original full res .obj file in the same zip as the downsampled one, even though this was an identical copy for the majority of maps (those with < 4M faces); this was not intentional, so we cleaned that up last week and going fwds only save the downsampled mesh + texture files. This means you will only be able to export the downsampled mesh.

I’d be interested to understand your use-case for the full resolution 3D model, as we had assumed most users relied on the point cloud or elevation models for detailed analysis. Can certainly look into bringing back a full res model if it is a highly valuable feature for you.

1 Like

Hi @jeremy! I work in the photovoltaic area, so we need a good model to show customers. We put the modules on the roof and show them to the customer. A beautiful appearance is essential for a good sale.

But the decimated model is not so good. The end result is very different. Look at this roof:

And I didn’t mention that the decimated model doesn’t load textures in Windows. To load, I need to open it in other software and export it again. The work is much greater.

My suggestion is: give the option to export the full resolution 3D model as well. I’m sure it is missing for many people.

1 Like

Do you know when this happened? I have OBJ’s from last week that have the native file.

That looks more like a poor model than low-res textures to me… What resolution does it say the model is? For instance this one is 2in/px.

This started to happen last Thursday, approximately. Until then, the export resolution was 2 in / px. Today, the resolution is 5 in / px. Look:

1 Like

That makes sense. My last one was Wednesday, flown on Tuesday and it had the full file. Also, on the export pane it did not state a resolution. I just did one a minute ago, it only has the decimated file and now states 2in/px, but has lower resolutions available… Maybe the account is limited to 5in/px?

I don’t know. But i can’t work with the decimated model. Is very poor. I need the full resolution model.

1 Like

You could try running your photos thru Agisoft’s Metashape program trial version to see if you can generate a better model. I have gotten better results with Metashape even before the DD .obj file resolution was reduced.


But DD has the resource, just make them available, as before. I was about to acquire the license, now I don’t know if I will acquire it anymore.

1 Like

I am more concerned with the model itself. Obviously the trial account has lower resolution output so running through Metashape as @SolarBarn suggested will be a pretty huge difference, but not exactly apples to apples. When I see waviness as I am seeing from your screenshot it usually means the image coverage wasn’t as good as it could have been and/or from the right angles, but if DroneDeploy is using a reduced file size @jeremy? then that can also contribute to a lesser point cloud and worse model.

If you would like to PM me I would be happy to run your project through our account so you can get a true comparison.

Seem to be a few different things going on here so I’ll try to address each below:

  • Model texture not loading in windows: this should have nothing to do with the decimated vs non-decimated .obj file. You will always have to load the .obj file and textures into special software to visualise the 3D scene. If you want to see the 2D map as a standalone image, just export the orthomosaic - the textures are not generated in a format which is useful to view independently. If you do have differences in loading the decimated vs non-decimated model + textures together, please let us know.

  • 2cm/pix vs 5cm/pix resolution: if you were on a trial previously you would have access to native resolution orthomosaics, however this is limited when you come off the trial. If you send me your DD username (feel free to DM for privacy) I can extend your trial so you can export / regenerate the map at higher resolution to test us out properly. N.b. the 3D model texture resolution will not be the same as the orthomosaic resolution (looks like a bug with our UI in the screenshot you showed - I’ll get that logged), but is also decimated to improve model loading. This has not changed recently (we have always decimated the model textures).

  • Artifacts with the model roof: this is unlikely to be related to the .obj decimation, rather an artifact we often see with distortion over corrugated roofs (something we are aware of and steadily working to resolve). Your post suggests that these artifacts were not present in the original undecimated .obj - if so could you please DM me the map link (can just send the url) as we definitely want to investigate.


Wasn’t it changed that there is now no activity once off the trial. There is no longer a free processing account unless that has changed again in the last year.

Only if the images were insufficiently acquired.

Yes, I know this. I use other software to view the model. But it is a fact that windows opened the full resolution 3d model and does not open the decimated.

In fact, I don’t use the orthomosaic map. I only use the 3D model. But last week I could obtain the full resolution 3D model. Today, I couldn’t. The decimated model doesn’t have the same quality of the decimated model. This is my problem.

I don’t know if this roof doesn’t have the artifacts in the undecimated .obj. Because I don’t have the undecimated, since this function was removed. But I can see the difference of quality between the decimated and undecimated models. Look:

The only thing I need is the full resolution 3D model back.

I get what you were saying about decimated vs. non-decimated… Do you think this is affecting the mesh as well?

I am seeing the same ripples in both models so i’m pretty sure it’s not the decimation. Unless DroneDeploy is removing points (better not be) it is just the resolution of the images. If there is less detail in the images the draping won’t look as good and the ripples will probably be more noticeable.

I don’t know the reason, I know they changed this. Why did they change something that was already good?

Developers do some strange things sometimes, but I think because what he said about the fact that most maps are the same because of the threshold they set for decimation so there was no need to process both. My thought is that there is something in the code of the decimated that is jacking with the software you are using. What we can do as users is make it a Feature Request and if enough people are having the same problem and chime in then it will get noticed.

I just wanted to put my 2 cents in on this one. I understand removing one of the models if they are identical, but to go from two identical models being downloaded if they were the same to only downloading one even if they’re different doesn’t make much sense to me. Wouldn’t it make more sense to the full resolution one all the time, which is what people would typically expect, and also include a decimated one if it’s different from the full one (>4M faces).


Personally I don’t believe in decimation of any aspect of data, but I do understand @mdowney that they have to cater to some services that require a much smaller dataset to be submitted. In those cases you have to produce two files anyway. In all seriousness though I can almost bet that people who would benefit from a huge OBJ of a large tract are more likely to be using the point cloud. Those that have to have the OBJ model probably don’t have the resources to use a point cloud and those are typically much smaller projects which never need a non-decimated file.

We need to be clear on the difference between a model looking bad because of a decimated resolution from just a poorly reconstructed mesh as seen above. We also need to know @jeremy exactly what DroneDeploy’s process is for decimation. Are you removing points and downsizing texture tiles?

Something I think we need to verify is that there isn’t something in a “decimated” file that is different and causing trouble with softwares where an otherwise non-decimated file would work.

To clarify the decimation of the mesh (the .obj file): this is a process done after the rest of the photogrammetry pipeline has completed, so has no impact whatsoever on the point cloud or elevation model - those are not downsampled at all, and there have been no changes made to these outputs in recent weeks. As you mentioned @MichaelL, our understanding thus far was that users wanting to deal with massive datasets, or performing detailed measurements / analysis were doing so on the elevation model or point cloud, rather than the 3d mesh, and that the 3D model was used mainly for a qualitative view of the scene. As such we optimised the file size of the model and textures for ease of display and interaction.

In terms of decimation of the 3D model and texture, we have always decimated the model and reduced the texture size to make the 3D model load efficiently in the browser, again our assumption being this was the primary use-case for the 3D model. The model texture downsampling has been the same for several years, and the texture files packaged up in the model.zip have always been downsampled (so there has been no change to them in the last week). The decimated mesh has always been the one we display in the browser, so there has been no change to the model quality you see in our UI.

We have done a fair amount of internal comparisons on the original full mesh and the decimated one we display in the UI and provide via export, and have found very little qualitative difference (certainly no introduction of major artifacts). That being said, there could well be an exception, which we would want to investigate and fix. @Charles_Trindade could you send me a link to the models you linked in your post and we can take a look on our end. We are continuously working on improving our 3D model quality (this is the primary goal of our dedicated photogrammetry team), so really appreciate any specific feedback or examples we can get.

1 Like

Wanted to update you all here: based on your feedback we have rolled back the change to only include the decimated model .obj file in the model export, so model exports for maps processed from the end of last week onwards should include both models again. @Charles_Trindade please let me know if you would like a trial extension to test this out again.

In addition, to simplify / clarify matters we will address the issue where we duplicated the models with < 4M faces, so if you have a small model you will only get a single .obj file in your model export, and it will have the original file name (“scene_mesh_textured.obj”). For larger models, where we do decimate the model for viewing in our interface, you will continue to receive both models in the zipfile. This change will be going out in the next couple of weeks.

1 Like