points module and huge coordinates ... problems

[bernd]

Point module seams to have problems with huge coordinates. Attached a little sample fild. Points are wrong after import!


- load file and check coordinates by

Code: Select all

>>> for v in App.ActiveDocument.pcl_huge_koordinates.Points.Points:
...     print(v)
... 
Vector (3565093120.0, 5934305280.0, 660.0)
Vector (3565093120.0, 5934305280.0, 364.0)
Vector (3565093120.0, 5934305280.0, 590.0)
Vector (3565093120.0, 5934305280.0, 552.0)
Vector (3565093120.0, 5934305280.0, 654.0)
Vector (3565093120.0, 5934305280.0, 677.0)
Vector (3565093120.0, 5934305280.0, 566.0)
Vector (3565093120.0, 5934305792.0, 770.0)
Vector (3565093120.0, 5934305792.0, 549.0)
Vector (3565093120.0, 5934305792.0, 674.0)

but the first ten lines from the file:

Code: Select all

3565093049.00 5934305258.00 660.00
3565093054.00 5934305280.00 364.00
3565093086.00 5934305327.00 590.00
3565093110.00 5934305371.00 552.00
3565093136.00 5934305420.00 654.00
3565093165.00 5934305466.00 677.00
3565093180.00 5934305510.00 566.00
3565093214.00 5934305559.00 770.00
3565093215.00 5934305580.00 549.00
3565093243.00 5934305631.00 674.00

OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.14709 (Git)
Build type: Release
Branch: master
Hash: faad5ea27301cb7af393a25d317c406d3098bafe
Python version: 2.7.14
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.2.0
Locale: German/Switzerland (de_CH)


remove txt

pcl-huge-koordinates.asc.txt

(1.76 KiB) Downloaded 34 times

[wmayer]

I guess Coin gets some problems with these huge coordinates. You can observe the same behaviour when creating e.g. a standard box and then set its placement to some huge numbers.
In case it helps it would be best to determine the gravity center of the point cloud and then subtract it from all points so that they lie around the origin in world coordinates.

[DeepSOIC]

What is the numeric precision of coordinates of points in Points module? If it's single precision, that may explain the problem.

[wmayer]

What is the numeric precision of coordinates of points in Points module? If it's single precision, that may explain the problem.

Why should this be a double vs. float problem? And btw, an SoCoordinate3 node uses floats, too.

[DeepSOIC]

Why should this be a double vs. float problem?

because integers in 32-bit float are accurate only up to about 17M. The numbers quoted above are around 3G, more than two orders of magnitude more than 17M, so I would expect rounding errors circa +-100

https://en.wikipedia.org/wiki/Single-pr ... ger_values


Am I missing some other, more substantial problem?

[bernd]

I would expect rounding errors circa +-100

thats true! See values in first post. The original cloud has 250000 points and yes error is around +-100 in any point.

Thanks guys for your input. With this informations I may find a way around the problem.

[wmayer]

The problem then it's not caused by the Points module but still by Coin3d itself. Here is an .iv file with the above coordinates and when loading it into FreeCAD it shows the same weird behaviour. When loading the file then it doesn't use the Points module but only functions of the OpenInventor API.

Code: Select all

#Inventor V2.1 ascii


Separator {

  DrawStyle {
    style POINTS
    pointSize 5
  }
  Separator {
    Coordinate3 {
      point [
3565093049.00 5934305258.00 660.00,
3565093054.00 5934305280.00 364.00,
3565093086.00 5934305327.00 590.00,
3565093110.00 5934305371.00 552.00,
3565093136.00 5934305420.00 654.00,
3565093165.00 5934305466.00 677.00,
3565093180.00 5934305510.00 566.00,
3565093214.00 5934305559.00 770.00,
3565093215.00 5934305580.00 549.00,
3565093243.00 5934305631.00 674.00,
3565093268.00 5934305675.00 700.00,
3565093273.00 5934305693.00 405.00,
3565093345.00 5934305791.00 899.00,
3565093335.00 5934305810.00 409.00,
3565093362.00 5934305857.00 551.00,
3565093390.00 5934305907.00 623.00,
3565093416.00 5934305953.00 724.00,
3565093455.00 5934306001.00 888.00,
3565093441.00 5934306020.00 320.00,
3565093468.00 5934306068.00 508.00,
3565093519.00 5934306120.00 841.00,
3565093536.00 5934306165.00 711.00,
3565093558.00 5934306211.00 752.00,
3565093583.00 5934306260.00 680.00,
3565093615.00 5934306309.00 857.00,
3565093611.00 5934306327.00 379.00,
3565093645.00 5934306377.00 604.00,
3565093674.00 5934306387.00 73.00,
3565093691.00 5934306451.00 790.00,
3565092781.00 5934304758.00 600.00,
3565092811.00 5934304804.00 626.00,
3565092840.00 5934304849.00 774.00,
3565092839.00 5934304871.00 432.00,
3565092870.00 5934304916.00 657.00,
3565092900.00 5934304964.00 893.00,
3565092903.00 5934304986.00 587.00,
3565092933.00 5934305029.00 678.00,
3565092956.00 5934305078.00 700.00,
3565092954.00 5934305095.00 378.00,
3565092989.00 5934305144.00 577.00,
3565093018.00 5934305189.00 678.00,
3565093023.00 5934305210.00 360.00,
3565093106.00 5934305260.00 1392.00,
3565093178.00 5934305295.00 2469.00,
3565093120.00 5934305288.00 1524.00,
3565093193.00 5934305315.00 2606.00,
3565093135.00 5934305308.00 1659.00,
3565093213.00 5934305342.00 2677.00,
3565093155.00 5934305335.00 1754.00,
3565093230.00 5934305366.00 2762.00,
          ]
    }
    PointSet {
      numPoints 50
    }
  }
}

[wmayer]

Btw, other applications suffer from the same problem. Here a list of the applications I tested after creating a ply or stl file:

• MeshLab
• CAD Assistant
• Blender
• CloudCompare

CloudCompare however realized these high numbers and warned the user.

[bernd]

a warning would be cool.

How would you guys cut the first five diggits from the x and y numbers before open the file in FreeCAD points?

[bernd]

such pcl are common on terrain geo coordinates. They usually have such big numbers. That is why z is not big.