Agisoft Metashape 1.6.0 pre-release

[Photo-Survey-]

Try to roll back to the 19.11.1 drivers if you are running the latest Adrenalin 2020 packages (19.12.1/19.12.2/20.1.1).

Mak


That appears to have fixed the issue, thank you so much!

[Mak11]

Try to roll back to the 19.11.1 drivers if you are running the latest Adrenalin 2020 packages (19.12.1/19.12.2/20.1.1).

Mak


That appears to have fixed the issue, thank you so much!

Glad to know that this worked. As I reported earlier in this thread, the AMD Adrenalin 2020 drivers have buggy/broken OpenCL/Compute support (at least on Radeon VII GPUs).

Mak

[Photo-Survey-]

Does Agisoft have a recommended driver for use with AMD cards?  I know these drivers are approved my Microsoft but testing by third party software makers would be helpful considering the cost of the software and GPU.  I bought the Radeon VII specifically for use with photogrammetry. 

[BjFaeTorphins]

Hello BjFaeTorphins,

I think that something messed up with the access rights - for some reason the created files cannot be removed or rewritten. Do you observe any similar behavior when trying to export anything from Metashape to the new file or to the file with existing filename?

Alexey

After the error happens the model.tmp directory mentioned in the error message is gone.  I've not seen any permission errors and the project file can be saved after the error.

Hi Alexey

I think I've figured out what is causing these errors.

I'm using a Synology NAS to store my models.  I have a fast SSD drive on my desktop computer which is continuously synchronised to a Work in Progress folder on the NAS.  When I want to do work on a model i copy the files for the model to be worked on from the main folder structure on the NAS to the Work in Progress folder on the NAS which is then automatically synchronised to the SSD drive on the desktop.  The software that does this synchronisation between the NAS and the desktop is called Synology Drive.  I've been disabling this software when doing mesh from depth maps for about a week now and not had any more errors.  Whereas, I was getting the file errors at least 50% of the time previously.

I have been using this arrangement for quite some time (since Photoscan v1.3.5) and not had the file errors before.  I suspect that it is something to do with the very high number and size of the temporary files that v1.6 mesh from depth maps out-of-core creates. 

I can live with this work-around but it would be more convenient if i didn't need to remember to switch off Synology Drive while running mesh from depth maps. Perhaps introducing a re-try of the file operation if i fails.

HTH
Brian.

Hi Alexey
I've changed my mind about the circumstances of these errors. 

I'm now quite sure its when .psx and .files are stored on the NAS mounted shared drive.  I checked and all of the errors that i've seen happen when those files are stored on the NAS and does not happen on my local SSD drive even if Synology Drive synchronisation is enabled.
HTH

[mcstieg]

Hello eltama,

Do you have these errors during the depth maps generation step or already during the mesh reconstruction (all depth maps are already generated)?

Just had the same error on Metashape 1.6.0 build 9925 at the end of mesh generation.
This project was stored on a folder that dropbox has access to. Maybe there is a similar problem with the access rights.

[Photo-Survey-]

Try to roll back to the 19.11.1 drivers if you are running the latest Adrenalin 2020 packages (19.12.1/19.12.2/20.1.1).

Mak


That appears to have fixed the issue, thank you so much!

Glad to know that this worked. As I reported earlier in this thread, the AMD Adrenalin 2020 drivers have buggy/broken OpenCL/Compute support (at least on Radeon VII GPUs).

Mak

Driver update, drivers 20.1.2 cause a system lockup during the dense cloud creation requiring a hard restart with the Radeon VII.  Would not recommend them,

[Mak11]

Try to roll back to the 19.11.1 drivers if you are running the latest Adrenalin 2020 packages (19.12.1/19.12.2/20.1.1).

Mak


That appears to have fixed the issue, thank you so much!

Glad to know that this worked. As I reported earlier in this thread, the AMD Adrenalin 2020 drivers have buggy/broken OpenCL/Compute support (at least on Radeon VII GPUs).

Mak

Driver update, drivers 20.1.2 cause a system lockup during the dense cloud creation requiring a hard restart with the Radeon VII.  Would not recommend them,

Thanks for the heads up. I didn't bother testing them as I was fairly certain that AMD didn't fix it (as I said in another post:it often takes them more than 6 months to fix compute related issues unfortunately).

Mak

[eltama]

20.1.3 is out today

[eltama]

Hello eltama,

Do you have these errors during the depth maps generation step or already during the mesh reconstruction (all depth maps are already generated)?

Just had the same error on Metashape 1.6.0 build 9925 at the end of mesh generation.
This project was stored on a folder that dropbox has access to. Maybe there is a similar problem with the access rights.

I have this error even in build 10009:

...
2020-01-21 19:33:17 Devices performance:
2020-01-21 19:33:17  - 2%    done by [GPU 1]  with timings: 315 s = 1% load hists + 67% load cams + 4% calcs
2020-01-21 19:33:17  - 49%    done by [GPU 2]  with timings: 315 s = 0% load hists + 45% load cams + 34% calcs
2020-01-21 19:33:17  - 49%    done by [GPU 3]  with timings: 315 s = 0% load hists + 48% load cams + 30% calcs
2020-01-21 19:33:27 finished group #36/60: 8625 cameras, 381.065 s working (0% files opening + 28% IO + 65% unpacking + 3% queueing)
2020-01-21 19:33:27 Initing hists in leaves group #37/60: [517; 528)...
2020-01-21 19:33:41 total cubes: 108995332 cubes, 1663.14 MB, 124.888 MB/s
2020-01-21 19:34:01 Data: 2494.71 MB hists, 39.9879 MB pyramid
2020-01-21 19:34:01 Found 3 GPUs in 0.002 sec (CUDA: 0.001 sec, OpenCL: 0.001 sec)
2020-01-21 19:34:02 [GPU 1] Using device: GeForce RTX 2070 SUPER, 40 compute units, free memory: 6711/8192 MB, compute capability 7.5
2020-01-21 19:34:02   driver/runtime CUDA: 10020/8000
2020-01-21 19:34:02   max work group size 1024
2020-01-21 19:34:02   max work item sizes [1024, 1024, 64]
2020-01-21 19:34:02 [GPU 2] Using device: GeForce RTX 2070 SUPER, 40 compute units, free memory: 6711/8192 MB, compute capability 7.5
2020-01-21 19:34:02   driver/runtime CUDA: 10020/8000
2020-01-21 19:34:02   max work group size 1024
2020-01-21 19:34:02   max work item sizes [1024, 1024, 64]
2020-01-21 19:34:02 [GPU 3] Using device: GeForce RTX 2080 Ti, 68 compute units, free memory: 9158/11264 MB, compute capability 7.5
2020-01-21 19:34:02   driver/runtime CUDA: 10020/8000
2020-01-21 19:34:02   max work group size 1024
2020-01-21 19:34:02   max work item sizes [1024, 1024, 64]
2020-01-21 19:36:55 [GPU 2] Exception!
2020-01-21 19:36:55 [GPU 3] Exception!
2020-01-21 19:36:55 [GPU 1] Exception!
2020-01-21 19:36:56 Peak memory used: 24.71 GB at 2020-01-21 15:58:16
2020-01-21 19:36:56 deleting all temporary files...
2020-01-21 19:37:14 done in 18.331 s
2020-01-21 19:37:14 Finished processing in 32796.9 sec (exit code 0)
2020-01-21 19:37:14 Error: Internal error 239166172! Info: {0x0, 0x0-2406x1584, 2406x1584}

Now I try to build mesh from Dense points

[Photo-Survey-]

20.1.3 is out today

Tried the new drivers, the system does not lock up anymore but the software stalls and won't continue during the dense cloud creation.  Back to 19.11.1

[BjFaeTorphins]

Hello BjFaeTorphins,

I think that something messed up with the access rights - for some reason the created files cannot be removed or rewritten. Do you observe any similar behavior when trying to export anything from Metashape to the new file or to the file with existing filename?

Alexey

After the error happens the model.tmp directory mentioned in the error message is gone.  I've not seen any permission errors and the project file can be saved after the error.

Hi Alexey

I think I've figured out what is causing these errors.

I'm using a Synology NAS to store my models.  I have a fast SSD drive on my desktop computer which is continuously synchronised to a Work in Progress folder on the NAS.  When I want to do work on a model i copy the files for the model to be worked on from the main folder structure on the NAS to the Work in Progress folder on the NAS which is then automatically synchronised to the SSD drive on the desktop.  The software that does this synchronisation between the NAS and the desktop is called Synology Drive.  I've been disabling this software when doing mesh from depth maps for about a week now and not had any more errors.  Whereas, I was getting the file errors at least 50% of the time previously.

I have been using this arrangement for quite some time (since Photoscan v1.3.5) and not had the file errors before.  I suspect that it is something to do with the very high number and size of the temporary files that v1.6 mesh from depth maps out-of-core creates. 

I can live with this work-around but it would be more convenient if i didn't need to remember to switch off Synology Drive while running mesh from depth maps. Perhaps introducing a re-try of the file operation if i fails.

HTH
Brian.

Hi Alexey
I've changed my mind about the circumstances of these errors. 

I'm now quite sure its when .psx and .files are stored on the NAS mounted shared drive.  I checked and all of the errors that i've seen happen when those files are stored on the NAS and does not happen on my local SSD drive even if Synology Drive synchronisation is enabled.
HTH

Alexey

This problem still happens with 1.6.1 build 10009.

[mcstieg]

Hi,

I've seen in API changelog  " Added Model.getActiveTexture() and Model.setActiveTexture()" methods.
I would like to switch programmatically between the different textures in order to make a capture of the textured model view for each of them.
Here's my code:

Code: [Select]

tex = Metashape.app.document.chunk.model.textures
num = 0
for i in tex:
Metashape.app.document.chunk.model.setActiveTexture(i,Metashape.Model.TextureType(i.type))
Capture = Metashape.app.captureModelView(width = 1114, height = 763, transparent = (True), hide_items = (True), source = Metashape.DataSource.ModelData, mode = Metashape.ModelViewMode.TexturedModelView)   
Cap = Metashape.Image(Capture.width, Capture.height, "RGBA", "U8")
Capture.save('C:/Users/.../Desktop/num{}.png'.format(num))
num +=1

But unfortunately it dosen't change the texture type of the model...
Any ideas please?

Is there a solution?
Thank you!

[Iluvathar]

thanks for the update, texture issue is solved !

[BjFaeTorphins]

Hello Brian,

Thank you for sending the sample image. It appears that the presence of the alpha-channel in the images is causing the problem with the GPU-based texture blending.

We''\ll try to implement the fix for the issue in the next version update, but meanwhile you should either disable GPU for the texture blending process or remove alpha channel from the source images.

I can confirm that this issue is fixed in v1.6.1 build 10009

[Alexey Pasumansky]

Hello mcstieg,

Set Active Texture command is designed to switch the textures of the same type within the same model. In such way the multiple textures per model can exist (do not mix with multi-page texture atlas), similar to several instances of the dense cloud, for example, in the same chunk.

Unfortunately, there's no way to switch the display mode of the Model view at the moment or define Normal/Occlusion/Diffuse texture type in the CaptureModelView command.