Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Obj I/O for mesh verts in floating point precision 64 #1570

Open
justinhchae opened this issue Jun 22, 2023 · 0 comments
Open

Obj I/O for mesh verts in floating point precision 64 #1570

justinhchae opened this issue Jun 22, 2023 · 0 comments

Comments

@justinhchae
Copy link

🚀 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:

  1. add high_precision bool flag to: load_obj, _load_obj, load_objs_as_meshes, MeshObjFormat
  2. in _load_obj, implement high_precision if True with:
    verts = _make_tensor(
        verts,
        cols=3,
        dtype=torch.float64 if high_precision else torch.float32,
        device=device,
    )  # (V, 3)
  1. in transforms.transform3d.py modify _broadcast_bmm from main to high-precision as follows:
# from
return a.bmm(b)

# to
return a.float().bmm(b.float()).type(a.dtype)

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:

# example obj verts sampled without high-precision fork
tensor([
      [692202.1875, 5336173.5000, 512.4358],     
      [692202.8125, 5336174.0000, 512.1414],
      [692202.1250, 5336174.0000, 512.5216],   
      ...,
      [692324.2500, 5336135.5000, 510.2307],
      [692349.1875, 5336142.0000, 526.5537], 
      [692352.4375, 5336169.5000, 522.2985]]
)
     
# example obj verts sampled with high-precision fork
tensor([
      [692202.1617, 5336173.5623, 512.4358], 
      [692202.7912, 5336174.0104, 512.1414],
      [692202.1285, 5336174.0917, 512.5216], 
      ..., 
      [692324.2332, 5336135.5843, 510.2307], 
      [692349.1590, 5336142.1059, 526.5537], 
      [692352.4089, 5336169.6091, 522.2984]],
      dtype=torch.float64
)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant