Is it just me? SimpleWriter scaled integer cartesianXYZ not reading into CloudCompare...

[nigels-com]

I'm chasing a problem with reading our point clouds into CloudCompare.
libE57Format is doing both the writing and and the reading, so it's a bit of a puzzle of which side is at fault.
Debugging CloudCompare Float cartesian co-ordinates works just fine, but not scaled integer ones.
Can anyone else confirm that their scaled integer cartesian point clouds are loading into CloudCompare, just fine?

[asmaloney]

I tried BunnyInt32.e57 from here and it works for me on CloudCompare 2.11.1 on macOS:

File's XML with data structure

<?xml version="1.0"?>
<e57Root type="Structure" xmlns="http://www.astm.org/COMMIT/E57/2010-e57-v1.0">
    <formatName type="String"><![CDATA[ASTM E57 3D Imaging Data File]]></formatName>
    <guid type="String"><![CDATA[{991574D2-854C-4CEF-8CB8-D0132E4BCD0A}]]></guid>
    <versionMajor type="Integer">1</versionMajor>
    <versionMinor type="Integer" />
    <e57LibraryVersion type="String"><![CDATA[InteliSum-LD3-Studio-V5.1-E57RefImpl-1.0.154-x86-windows]]></e57LibraryVersion>
    <coordinateMetadata type="String" />
    <creationDateTime type="Structure">
        <dateTimeValue type="Float">9.8736541709700918e+008</dateTimeValue>
        <isAtomicClockReferenced type="Integer" />
    </creationDateTime>
    <data3D type="Vector" allowHeterogeneousChildren="1">
        <vectorChild type="Structure">
            <guid type="String"><![CDATA[{9CA24C38-C93E-40E8-A366-F49977C7E3EB}]]></guid>
            <name type="String"><![CDATA[bunny]]></name>
            <temperature type="Float" />
            <cartesianBounds type="Structure">
                <xMinimum type="Float">-9.4688999999999995e-002</xMinimum>
                <xMaximum type="Float">6.1008999999999994e-002</xMaximum>
                <yMinimum type="Float">4.0010999999999998e-002</yMinimum>
                <yMaximum type="Float">1.8732099999999999e-001</yMaximum>
                <zMinimum type="Float">-6.1872999999999997e-002</zMinimum>
                <zMaximum type="Float">5.8798999999999997e-002</zMaximum>
            </cartesianBounds>
            <points type="CompressedVector" fileOffset="48" recordCount="30571">
                <prototype type="Structure">
                    <cartesianX type="ScaledInteger" minimum="-2147483648" maximum="2147483647" scale="9.9999999999999995e-007" />
                    <cartesianY type="ScaledInteger" minimum="-2147483648" maximum="2147483647" scale="9.9999999999999995e-007" />
                    <cartesianZ type="ScaledInteger" minimum="-2147483648" maximum="2147483647" scale="9.9999999999999995e-007" />
                    <cartesianInvalidState type="Integer" minimum="0" maximum="1" />
                </prototype>
                <codecs type="Vector" allowHeterogeneousChildren="1" />
            </points>
        </vectorChild>
    </data3D>
    <images2D type="Vector" allowHeterogeneousChildren="1" />
</e57Root>

So at least reading them appears to work?

[asmaloney]

BTW - CloudCompare doesn't use the E57Simple* API, so that would certainly be a place to look if that's what you are using.

[nigels-com]

I did get to the bottom of this.

The Quaternion in E57SimpleWriter defaults to an invalid [0,0,0,0].
CloudCompare doesn't check for valid quaternion, resulting in all-zero transformation matrix.
So potentially there is a fix for all three parties to this - my writer, E57SimpleWriter and CloudCompare.
But I'll go study the specification to see what's intended for this corner case.
Is [0,0,0,0] an undefined Quaternion or a malformed E57 file?

[asmaloney]

8.4.8.2 The transform consists of a rotation, stored as a unit-length quaternion, and a translation.

It would seem to me that it's a malformed E57 file if it is not a unit-length quaternion.

[nigels-com]

Alright, will file a PR to fix libE57Format to default to identity quaternion.

[asmaloney]

Fixed by #108.