You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When reading obj files of real-world meshes that may represent multiple city blocks and with vertex coordinates in projected spatial coordinates, the absolute values of the vertices can be so large that they are rounded because load_obj forces values into floating point 32. This essentially is a significant loss in numeric precision. In some cases, the values are rounded to the nearest whole number which leads to meshes that render jagged faces. Further, if sampling a point cloud from a mesh, the resulting xyz coordinates produce points that are also rounded. The result are xyz data that do not sufficiently mimic point clouds that one might expect from random sampling.
An example cited in medium.com demonstrates what happens to the input vertices when coordinate values are rounded in fp.32:
The obj is a common data structure used to represent both objects such as the spherical cow in a vacuum as well as real-world photogrammetric meshes of buildings and terrain. For either situation, there is a general case that benefits all users with increased precision in face vertices when reading from obj files. Faces with vertices in floating point 64 allow for greater granularity and enable downstream workflows that may rely on differentiating between geometric features of a mesh.
The text was updated successfully, but these errors were encountered:
🚀 Feature
This is a feature request to enable load_obj to optionally read obj vertices with floating point precision 64 instead of 32.
A working fork that implements this feature is available for evaluation at esri/pytorch3d.
Background about this feature and related issues are further described at geoai/pytorch3d.
Key changes to the API include the following:
Motivation
When reading obj files of real-world meshes that may represent multiple city blocks and with vertex coordinates in projected spatial coordinates, the absolute values of the vertices can be so large that they are rounded because load_obj forces values into floating point 32. This essentially is a significant loss in numeric precision. In some cases, the values are rounded to the nearest whole number which leads to meshes that render jagged faces. Further, if sampling a point cloud from a mesh, the resulting xyz coordinates produce points that are also rounded. The result are xyz data that do not sufficiently mimic point clouds that one might expect from random sampling.
An example cited in medium.com demonstrates what happens to the input vertices when coordinate values are rounded in fp.32:
Pitch
The obj is a common data structure used to represent both objects such as the spherical cow in a vacuum as well as real-world photogrammetric meshes of buildings and terrain. For either situation, there is a general case that benefits all users with increased precision in face vertices when reading from obj files. Faces with vertices in floating point 64 allow for greater granularity and enable downstream workflows that may rely on differentiating between geometric features of a mesh.
The text was updated successfully, but these errors were encountered: