CloudCompare forum

I'v tried this with CC 2.8 and 2.7 on 64bit windows. What I did:

I used the RANSAC plugin to find a bunch of planes from a point cloud, this worked fine. After that I wanted to save these clouds to one or more E57 files. I managed to save them as ascii files (CC automatically named the fiels with xxxx_000000.txt and so on), but trying the same procedure, but setting output format to E57 yields an error (console: [10:08:28] [E57] LibE57 has thrown an exception: namespace prefix already defined (E57_ERROR_DUPLICATE_NAMESPACE_PREFIX) ). I can save the individual planes by selecting each child tree in turn, but te amount of them makes this a bad solution.

So, how can I circumvent this issue?

Can you save the exact same selection you are trying to save as E57 but as a BIN file and send it to me? (cloudcompare [at] danielgm.net). I'll try to reproduce the issue on my side (it's probably a bug).

Sure enough, saving as a single .bin worked. I'll try with some other cloud that's not work related and if I can replicate it, I'll send that bin.

This was indeed a bug. You can download the online 2.8 beta version. It's fixed.

Thanks for the feedback.

Okay, now the (7z version) beta version wont run for me anymore. Popup error message:

"
...(path)...\CloudCompare_c2.8.0.beta_bin_x64\CloudCompare.exe
The application failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
"

Ah yes, I forgot to remove the 'CloudCompare.exe.manifest' file (next to CloudCompare.exe).

Ok, that was he glitch.

Managed to open the bin I sent and save it as E57. Although I had to change the path as it contained spaces and non-latin characters. Bin saving did not mind that though.

Anyway, now exporting is working, thanks.

Yes, libE57 (the library that handles the E57 file creation) doesn't support special characters. While BIN files are saved by CC itself (with Qt, that does support special characters).

Hmm.. so how come before this fix I could export e57 to the same directory that now throws an exception?

Also I can no longer open files from it, previously there was no problem whether it was from file->open or drag&drop.

Is this a trade-off situation, you can export or open but not both =)

No it's because there was no protection against special characters before (it's a recent addition).

What error do you get when opening files now?