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:
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.
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.
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.
