I’ve been given point cloud data in E57 format but importing these files results in the point cloud being squashed in one axis so that the resulting point cloud is flat (all points on a 2D plane).
The E57 data imports fine in Faro’s Scene so it looks like the data itself is correct.
Re-exporting from Faro’s Scene as E57 produces the same error when imported with Krakatoa, but the ‘point plane’ is oriented differently.
Exporting as PTS imports fine so it looks like a problem with E57 data specifically.
I can get around the issue by using PTS but wanted to make sure it’s reported. I vaguely remember seeing this 2 or 3 years ago already but didn’t report back then, I hope that reporting now helps to get it fixed.
Let me know if you need an example file to reproduce the issue.
I am preparing a zip for you with two files of the same point cloud, one as E57, another as PTS so you can see the differences.
One thing I came across yesterday - something which would be just another bug - is that the PTS point cloud seems to import with one axis inverted. This hasn’t happened the last time I used exactly the same workflow some 2-3 years ago. Looks like you need to check and make sure the importers work correctly. Can you investigate this as well?
I’ll PM you the download link for the E57/PTS data.
Sorry, I made a mistake! The PTS point cloud is NOT mirrored, I was looking in the wrong place. So, PTS is fine, it’s only the E57 format that has issues.
Evan, I just sent you a message but I’m afraid I don’t understand the messaging system here and it may not have reached you. I sent you a link to the file in question, and today I also sent you the password for the zip which I forgot in my original message.
Please contact me at mg[at]mswee.net if you didn’t receive any message or for any additional questions. Thank you!
I’ve taken a look at the e57 file you sent me and I wasn’t able to reproduce the issue.
Could you please tell me which version of Krakatoa MX and 3ds Max you’re experiencing the issue with? Additionally, would it be possible to get a screenshot of your “Modify” panel with the PRTLoader you’re using to load the e57 file selected?
I tested with a bunch of E57s I have around here, and the latest Krakatoa MX 2.8.6, but was unable to reproduce this behavior. So my suspicion is there is something about this particular E57 we are not handling right.
Does this happen to all E57 files you have access to, or just this specific one?
For me this happens with any E57 file… hmm, could it be a OS locale issue? I’m on a German OS and keyboard layout. Judging from past experience, the comma vs dot decimal separator regularly causes problems unless specifically taken care of, maybe it’s part of the problem with the E57 import, too?
You can change the decimal symbol of your Windows OS and try again.
It is under Windows Einstellungen > Zeit- und Spracheinstellungen > Region > Zusätzliche Datums-, Uhrzeit- und Ländereinstellungen > Region (Datums-, Zeit- oder Zahlenformate ändern) > Zusätzliche Einstellungen
Change Decimal Symbol to . and Digit Grouping Symbol to , to match the US layout.
I tried switching the . and , on my computer, but this caused the E57 I tried to load to fail with an E57_ERROR_VALUE_OUT_OF_BOUNDS.
I can confirm that the German (comma , ) decimal delimiter causes the problem with your E57 file.
With a US period . it loads as it should.
We will explore if we can force the correct formatting in our E57 loader to avoid this in the future.
For now, the workaround would be to switch your OS number settings to use . instead of , for the decimals.
