Summary: 3 extend functions in textures.py updated to call `self.__class__` rather than create a new object of its type. As mentioned in https://github.com/facebookresearch/pytorch3d/issues/618 .
Reviewed By: bottler
Differential Revision: D28281218
fbshipit-source-id: b9c99ab87e46a3f28c37efa1ee2c2dceb560b491
Summary: Add ability to load normals when they are present in a PLY file.
Reviewed By: nikhilaravi
Differential Revision: D26458971
fbshipit-source-id: 658270b611f7624eab4f5f62ff438038e1d25723
Summary: Save existing vertex normals when a mesh is saved to PLY, and existing normals when a point cloud is saved to PLY.
Reviewed By: theschnitz
Differential Revision: D27765257
fbshipit-source-id: fa0aae4c0f100f7e5eb742f48fc3dfc87435deba
Summary: Add ability to ask a Meshes if it already has normals. If it does, then requesting normals will not trigger a calculation. MeshesFormatInterpreters will therefore be able to decide whether to save normals.
Reviewed By: theschnitz, nikhilaravi
Differential Revision: D27765261
fbshipit-source-id: 7c87dbf999d5616d20f5eb2c01039ee5ff65a830
Summary: Add ability to set the vertex normals when creating a Meshes, so that the pluggable loaders can return them from a file.
Reviewed By: nikhilaravi
Differential Revision: D27765258
fbshipit-source-id: b5ddaa00de3707f636f94d9f74d1da12ecce0608
Summary: If offset_verts_ is used to move meshes with a single vector, the normals won't change so don't need to recalculate. I am planning to allow user-specified vertex normals. This change means that user-specified vertex normals won't get overwritten when they don't need to be.
Reviewed By: nikhilaravi
Differential Revision: D27765256
fbshipit-source-id: f6e4d308ac9ac023030325cb75a18d39b966cf88
Summary:
There is no need to recalculate normals when scaling a mesh by a constant. We omit doing this for vertex normals. This will make things less confusing when we allow user-specified vertex normals.
Face normals also don't need recalculating, but they are calculated at the same time as face areas which do, so it is easiest not to change their behavior here. That is convenient because we are not immediately planning to allow user-specified face normals.
Reviewed By: nikhilaravi
Differential Revision: D27793476
fbshipit-source-id: 827f1be4bc78bf0391ce3959cce48c4f3ee326fe
Summary: When a PLY file contains colors in byte format, these are now scaled from 0..255 to [0,1], as they should be
Reviewed By: gkioxari
Differential Revision: D27765254
fbshipit-source-id: 526b5f5149d5e8cbffd7412b411be52c935fa4ad
Summary:
Include TexturesVertex colors when loading and saving Meshes to PLY files.
A couple of other improvements to the internals of ply_io, including using `None` instead of empty tensors for some missing data.
Reviewed By: gkioxari
Differential Revision: D27765260
fbshipit-source-id: b9857dc777c244b9d7d6643b608596d31435ecda
Summary: We can check the bounds without using extra memory. This produces a small speedup in NeRF training (like 0.5%).
Reviewed By: nikhilaravi
Differential Revision: D27859691
fbshipit-source-id: d566420c465f51231f4a57438084c98b73253046
Summary:
When a list of Meshes is `join_batched()`, the `num_verts_per_mesh` in the list would be unexpectedly modified.
Also some cleanup around `_num_verts_per_mesh`.
Pull Request resolved: https://github.com/facebookresearch/pytorch3d/pull/623
Test Plan: A modification to an existing test checks this.
Reviewed By: nikhilaravi
Differential Revision: D27682104
Pulled By: bottler
fbshipit-source-id: 9d00913dfb4869bd6c7d3f5cc9156b7b6f1aecc9
Summary:
Update `main` build to latest CircleCI image - Ubuntu 2020.04.
Avoid torch.logical_or and logical_and for PyTorch 1.4 compatibility.
Also speed up the test run with Pytorch 1.4.0 (which has no ninja) by not setting NVCC_FLAGS for it.
Reviewed By: theschnitz
Differential Revision: D27262327
fbshipit-source-id: ddc359d134b1dc755f8b20bd3f33bb080cb3a0e1
Summary: Make black and isort stop disagreeing by removing some unneeded comments around import statements. pyre ignores are moved.
Reviewed By: theschnitz
Differential Revision: D27118137
fbshipit-source-id: 9926d0f21142adcf9b5cfe1d394754317f6386df
Summary: When viewing two or more pointclouds in a single plot, we should be subsampling each one separately rather than subsampling their union.
Reviewed By: nikhilaravi
Differential Revision: D27010770
fbshipit-source-id: 3c7e04a6049edd39756047f985d5a82c2601b3a2
Summary: Small change to swap how height/width are inferred from the image_size setting.
Reviewed By: gkioxari
Differential Revision: D26648340
fbshipit-source-id: 2c657a115c96cadf3ac63be87b0e1bfba10c9315
Summary:
- Fix the calculation of the non square NDC range when the H and W are not integer multiples.
- Add test for this case
Reviewed By: gkioxari
Differential Revision: D26613213
fbshipit-source-id: df6763cac602e9f1d516b41b432c4d2cfbaa356d
Summary: Implements the ascii OFF file format. This was discussed in https://github.com/facebookresearch/pytorch3d/issues/216
Reviewed By: theschnitz
Differential Revision: D25788834
fbshipit-source-id: c141d1f4ba3bad24e3c1f280a20aee782bfd74d6
Summary: One step in finding all the pairs of vertices which share faces is a simple calculation but annoying to parallelize. It was implemented in pure Python. We move it to C++. We still pull the data to the CPU and put the answer back on the device.
Reviewed By: nikhilaravi, gkioxari
Differential Revision: D26073475
fbshipit-source-id: ffbf4e2c347a511ab5084bceff600465812b6a52
Summary:
Fixes mostly related to the "main" build on circleci.
-Avoid error to do with tuple copy from initializer_list which is `explicit` on old compiler.
-Add better reporting to copyright test.
-Move to PackedTensorAccessor64 from the deprecated PackedTensorAccessor
-Avoid some warnings about mismatched comparisons.
The "main" build is the only one that runs the test_build stuff. In that area
-Fix my bad copyright fix D26275931 (3463f418b8) / 965c9c
-Add test that all tutorials are valid json.
Reviewed By: nikhilaravi
Differential Revision: D26366466
fbshipit-source-id: c4ab8b7e6647987069f7cb7144aa6ab7c24bcdac
Summary:
- Updated the C++/CUDA mesh rasterization kernels to handle the clipped faces. In particular this required careful handling of the distance calculation for faces which are cut into a quadrilateral by the image plane and then split into two sub triangles i.e. both sub triangles can't be part of the top K faces.
- Updated `rasterize_meshes.py` to use the utils functions to clip the meshes and convert the fragments back to in terms of the unclipped mesh
- Added end to end tests
Reviewed By: jcjohnson
Differential Revision: D26169685
fbshipit-source-id: d64cd0d656109b965f44a35c301b7c81f451cfa0
Summary: Small update to the cameras and rasterizer to correctly infer the type of camera (perspective vs orthographic).
Reviewed By: jcjohnson
Differential Revision: D26267225
fbshipit-source-id: a58ed3bc2ab25553d2a4307c734204c1d41b5176
Summary:
This diff adds utils functions for converting rasterization fragments of the clipped mesh into fragments expressed in terms of the original unclipped mesh.
The face indices and barycentric coordinates are converted in this step. The pixel to triangle distances are handled in the rasterizer which is updated in the next diff in the stack.
Reviewed By: jcjohnson
Differential Revision: D26169539
fbshipit-source-id: ba451d3facd60ef88a8ffaf25fd04ca07b449ceb
Summary:
Instead of culling faces behind the camera, partially clip them if they intersect with the image plane.
This diff implements the utils functions for clipping.
There are 4 cases for the mesh faces which are all handled:
```
Case 1: the triangle is completely in front of the clipping plane (it is left
unchanged)
Case 2: the triangle is completely behind the clipping plane (it is culled)
Case 3: the triangle has exactly two vertices behind the clipping plane (it is
clipped into a smaller triangle)
Case 4: the triangle has exactly one vertex behind the clipping plane (it is clipped
into a smaller quadrilateral and divided into two triangular faces)
```
Reviewed By: jcjohnson
Differential Revision: D23108673
fbshipit-source-id: 550a8b6a982d06065dff10aba10d47e8b144ae52
Summary: Corner case where there's nothing to do in this function.
Reviewed By: nikhilaravi
Differential Revision: D26073476
fbshipit-source-id: eb061683ffe35c1ffa8384c422a1557a636d52cd
Summary: We were double counting some pairs in some cases. Specifically if four or more faces share an edge, then some of them were getting double counted. This is a minimal tweak to avoid that.
Reviewed By: nikhilaravi
Differential Revision: D26073477
fbshipit-source-id: a40032acf3044bb98dd91cb29904614ef64d5599
Summary:
Fixes the assertion that `p1` and `p2` have the same last dimension. The issue was that `D` is set to equal `p2.size(2)`, and then `D` is compared to `p2.size(2)`. The fix instead compares `D` to `p1.size(2).
Pull Request resolved: https://github.com/facebookresearch/pytorch3d/pull/524
Reviewed By: bottler
Differential Revision: D26008688
Pulled By: nikhilaravi
fbshipit-source-id: e32afe9da127d81b1a411d3c223b539a7400597b
Summary: We previously did not send an `up` vector in to plotly when visualization_cameras is supplied. This meant the image would have the default orientation instead of the correct one. Now we use the library function `camera_to_eye_at_up` to calculate the plotly position, which includes the `up` vector.
Reviewed By: nikhilaravi
Differential Revision: D25981183
fbshipit-source-id: abec72b349f3a5519209e0e6c0518133c3750807
Summary:
Plotly viewing from a specific camera location requires converting that location in to an (eye, at, up) specification. There may be other reasons to want to do this as well. I create a separate utility function for it.
I envisage more such utility functions for manipulating camera information, so I create a separate camera_utils.py file for such things.
Reviewed By: nikhilaravi
Differential Revision: D25981184
fbshipit-source-id: 0947bf98b212676c021f2fddf775bf436dee3487
Summary:
It is common when trying things out to want to move a whole mesh or point cloud by the same amount. Here we allow the offset functions to broadcast.
Also add a sanity check to join_meshes_as_scene which it is easy to call wrongly.
Reviewed By: nikhilaravi
Differential Revision: D25980593
fbshipit-source-id: cdf1568e1317e3b81ad94ed4e608ba7eef81290b
Summary: Make `to` on Transform3D carry its member _transforms.
Reviewed By: nikhilaravi
Differential Revision: D25978611
fbshipit-source-id: 12b39e7a657f28d59ca60800bf9f4193a2c08197
Summary: Gradient calculation flags were not properly routed through the Python interface. This diff fixes this. In particular, gradients for focal length (only if no other camera gradients were calculated) and opacity were not calculated as required.
Reviewed By: gkioxari
Differential Revision: D25921202
fbshipit-source-id: 22cbae3bda886d81bb95878f0be45c2ddd29934c
Summary:
Allow PLY files to not contain faces. Allow loading pointclouds with color, at least encoded according to the way of some cloudcompare examples.
TODO: Allow vertex normals to be read, and allow vertex colors to be written. Make the return type of load_ply something more user friendly, like a dict.
Noticed in https://github.com/facebookresearch/pytorch3d/issues/209
Reviewed By: nikhilaravi
Differential Revision: D22573314
fbshipit-source-id: 72ba1f7c6417f5dfc83f2ebf359eff017057635c
Summary:
In the original implementation, I had considered PLY properties where there are mixed types of elements in a property to be rare and basically unimportant, so the implementation is very naive.
If we want to support pointcloud PLY files, we need to handle at least the subcase where there are no lists efficiently because this seems to be very common there.
Reviewed By: nikhilaravi, gkioxari
Differential Revision: D22573315
fbshipit-source-id: db6f29446d4e555a2e2b37d38c8e4450d061465b
Summary: We already have code for obj and ply formats. Here we actually make it available in `IO.load_mesh` and `IO.save_mesh`.
Reviewed By: theschnitz, nikhilaravi
Differential Revision: D25400650
fbshipit-source-id: f26d6d7fc46c48634a948eea4d255afad13b807b
