Summary:
Efficient PnP algorithm to fit 2D to 3D correspondences under perspective assumption.
Benchmarked both variants of nullspace and pick one; SVD takes 7 times longer in the 100K points case.
Reviewed By: davnov134, gkioxari
Differential Revision: D20095754
fbshipit-source-id: 2b4519729630e6373820880272f674829eaed073
Summary: Made a CameraBase class. Added `unproject_points` method for each camera class.
Reviewed By: nikhilaravi
Differential Revision: D20373602
fbshipit-source-id: 7e3da5ae420091b5fcab400a9884ef29ad7a7343
Summary: Estimates normals of a point cloud.
Reviewed By: gkioxari
Differential Revision: D20860182
fbshipit-source-id: 652ec2743fa645e02c01ffa37c2971bf27b89cef
Summary: knn is more general and faster than the nearest_neighbor code, so remove the latter.
Reviewed By: gkioxari
Differential Revision: D20816424
fbshipit-source-id: 75d6c44d17180752d0c9859814bbdf7892558158
Summary:
Allow Pointclouds objects and heterogenous data to be provided for Chamfer loss. Remove "none" as an option for point_reduction because it doesn't make sense and in the current implementation is effectively the same as "sum".
Possible improvement: create specialised operations for sum and cosine_similarity of padded tensors, to avoid having to create masks. sum would be useful elsewhere.
Reviewed By: gkioxari
Differential Revision: D20816301
fbshipit-source-id: 0f32073210225d157c029d80de450eecdb64f4d2
Summary: Interface and working implementation of ragged KNN. Benchmarks (which aren't ragged) haven't slowed. New benchmark shows that ragged is faster than non-ragged of the same shape.
Reviewed By: jcjohnson
Differential Revision: D20696507
fbshipit-source-id: 21b80f71343a3475c8d3ee0ce2680f92f0fae4de
Summary: The conda build process generates some files of its own, which we don't want to catch in our test for copyright notices.
Reviewed By: nikhilaravi, patricklabatut
Differential Revision: D20868566
fbshipit-source-id: 76a786a3eb9a674d59e630cc06f346e8b82258a4
Summary:
Allows to initialize a Transform3D object with a batch of user-defined transformation matrices:
```
t = Transform3D(matrix=torch.randn(2, 4, 4))
```
Reviewed By: nikhilaravi
Differential Revision: D20693475
fbshipit-source-id: dccc49b2ca4c19a034844c63463953ba8f52c1bc
Summary:
1. Introduced weights to Umeyama implementation. This will be needed for weighted ePnP but is useful on its own.
2. Refactored to use the same code for the Pointclouds mask and passed weights.
3. Added test cases with random weights.
4. Fixed a bug in tests that calls the function with 0 points (fails randomly in Pytorch 1.3, will be fixed in the next release: https://github.com/pytorch/pytorch/issues/31421 ).
Reviewed By: gkioxari
Differential Revision: D20070293
fbshipit-source-id: e9f549507ef6dcaa0688a0f17342e6d7a9a4336c
Summary:
Similar to D20392526, PLY files without vertices or faces should be allowed:
- a PLY with only vertices can represent a point cloud
- a PLY without any vertex or face is just empty
- a PLY with faces referencing inexistent vertices has invalid data
Reviewed By: gkioxari
Differential Revision: D20400330
fbshipit-source-id: 35a5f072603fd221f382c7faad5f37c3e0b49bb1
Summary: Run linter after recent changes. Fix long comment in knn.h which clang-format has reflowed badly. Add crude test that code doesn't call deprecated `.type()` or `.data()`.
Reviewed By: nikhilaravi
Differential Revision: D20692935
fbshipit-source-id: 28ce0308adae79a870cb41a810b7cf8744f41ab8
Summary:
OBJ files without vertices or faces should be allowed:
- an OBJ with only vertices can represent a point cloud
- an OBJ without any vertex or face is just empty
- an OBJ with faces referencing inexistent vertices has invalid data
Reviewed By: gkioxari
Differential Revision: D20392526
fbshipit-source-id: e72c846ff1e5787fb11d527af3fefa261f9eb0ee
Summary:
Implements K-Nearest Neighbors with C++ and CUDA versions.
KNN in CUDA is highly nontrivial. I've implemented a few different versions of the kernel, and we heuristically dispatch to different kernels based on the problem size. Some of the kernels rely on template specialization on either D or K, so we use template metaprogramming to compile specialized versions for ranges of D and K.
These kernels are up to 3x faster than our existing 1-nearest-neighbor kernels, so we should also consider swapping out `nn_points_idx` to use these kernels in the backend.
I've been working mostly on the CUDA kernels, and haven't converged on the correct Python API.
I still want to benchmark against FAISS to see how far away we are from their performance.
Reviewed By: bottler
Differential Revision: D19729286
fbshipit-source-id: 608ffbb7030c21fe4008f330522f4890f0c3c21a
Summary: use assertClose in some tests, which enforces shape equality. Fixes some small problems, including graph_conv on an empty graph.
Reviewed By: nikhilaravi
Differential Revision: D20556912
fbshipit-source-id: 60a61eafe3c03ce0f6c9c1a842685708fb10ac5b
Summary:
Create extrinsic parameters from eye point.
Create the rotation and translation from an eye point, look-at point and up vector.
see:
https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluLookAt.xml
It is arguably easier to initialise a camera position as a point in the world rather than an angle.
Pull Request resolved: https://github.com/facebookresearch/pytorch3d/pull/65
Reviewed By: bottler
Differential Revision: D20419652
Pulled By: nikhilaravi
fbshipit-source-id: 9caa1330860bb8bde1fb5c3864ed4cde836a5d19
Summary: Added a padded to packed utils function which takes either split sizes or a padding value to remove padded elements from a tensor.
Reviewed By: gkioxari
Differential Revision: D20454238
fbshipit-source-id: 180b807ff44c74c4ee9d5c1ac3b5c4a9b4be57c7
Summary: Use more realistic number of vertices / faces in benchmarks: in typical meshes, |F| ~ 2 |V| (follows from Euler formula + triangles as faces)
Reviewed By: nikhilaravi
Differential Revision: D20390722
fbshipit-source-id: d615e5810d6f4521391963b2573497c08a58db80
Summary:
Rename mesh I/O benchmarks and associated methods:
- add `simple` qualifier (benchmark on more realistic mesh data to be added later)
- align naming between OBJ and PLY
- prefix with `bm_` to make the benchmarking purpose clear(er)
Reviewed By: nikhilaravi
Differential Revision: D20390764
fbshipit-source-id: 7714520abfcfe1125067f3c52f7ce19bca359574
Summary: The shebang line `#!<path to interpreter>` is only required for Python scripts, so remove it on source files for class or function definitions. Additionally explicitly mark as executable the actual Python scripts in the codebase.
Reviewed By: nikhilaravi
Differential Revision: D20095778
fbshipit-source-id: d312599fba485e978a243292f88a180d71e1b55a
Summary: Make Meshes.__getitem__ carry texture information to the new mesh.
Reviewed By: gkioxari
Differential Revision: D20283976
fbshipit-source-id: d9ee0580c11ac5b4384df9d8158a07e6eb8d00fe
Summary:
## Updates
- Defined the world and camera coordinates according to this figure. The world coordinates are defined as having +Y up, +X left and +Z in.
{F230888499}
- Removed all flipping from blending functions.
- Updated the rasterizer to return images with +Y up and +X left.
- Updated all the mesh rasterizer tests
- The expected values are now defined in terms of the default +Y up, +X left
- Added tests where the triangles in the meshes are non symmetrical so that it is clear which direction +X and +Y are
## Questions:
- Should we have **scene settings** instead of raster settings?
- To be more correct we should be [z clipping in the rasterizer based on the far/near clipping planes](https://github.com/ShichenLiu/SoftRas/blob/master/soft_renderer/cuda/soft_rasterize_cuda_kernel.cu#L400) - these values are also required in the blending functions so should we make these scene level parameters and have a scene settings tuple which is available to the rasterizer and shader?
Reviewed By: gkioxari
Differential Revision: D20208604
fbshipit-source-id: 55787301b1bffa0afa9618f0a0886cc681da51f3
Summary:
Revisions to Poincloud data structure with added normals
The biggest changes form the previous version include:
a) If the user provides tensor inputs, we make no assumption about padding. Padding is only for internal use for us to convert from list to padded
b) If features are not provided or if the poincloud is empty, all forms of features are None. This is so that we don't waste memory on holding dummy tensors.
Reviewed By: nikhilaravi
Differential Revision: D19791851
fbshipit-source-id: 7e182f7bb14395cb966531653f6dd6b328fd999c
Summary:
Changed `torch.cumprod` to `torch.prod` in blending functions and added more tests and benchmark tests.
This should fix the issue raised on GitHub.
Reviewed By: gkioxari
Differential Revision: D20163073
fbshipit-source-id: 4569fd37be11aa4435a3ce8736b55622c00ec718
Summary:
Updates to the Renderer to enable barycentric clipping. This is important when there is blurring in the rasterization step.
Also added support for flat shading.
Reviewed By: jcjohnson
Differential Revision: D19934259
fbshipit-source-id: 036e48636cd80d28a04405d7a29fcc71a2982904
Summary:
BlendParams background_color is immutable , type hint as a sequence allows setting new values in constructor.
Pull Request resolved: https://github.com/facebookresearch/pytorch3d/pull/64
Reviewed By: bottler
Differential Revision: D20068911
Pulled By: nikhilaravi
fbshipit-source-id: c580a7654dca25629218513841aa16d9d1055588
Summary:
Lint related fixes: Improve internal/OSS consistency. Fix the fight between black and certain pyre-ignore markers by moving them to the line before.
Use clang-format-8 automatically if present. Small number of pyre fixes.
arc doesn't run pyre at the moment, so I put back the explicit call to pyre. I don't know if there's an option somewhere to change this.
Reviewed By: nikhilaravi
Differential Revision: D19780518
fbshipit-source-id: ef1c243392322fa074130f6cff2dd8a6f7738a7f
Summary:
Added backward for mesh face areas & normals. Exposed it as a layer. Replaced the computation with the new op in Meshes and in Sample Points.
Current issue: Circular imports. I moved the import of the op in meshes inside the function scope.
Reviewed By: jcjohnson
Differential Revision: D19920082
fbshipit-source-id: d213226d5e1d19a0c8452f4d32771d07e8b91c0a
Summary:
Renamed shaders to be prefixed with Hard/Soft depending on if they use a probabalistic blending (Soft) or use the closest face (Hard).
There is some code duplication but I thought it would be cleaner to have separate shaders for each task rather than:
- inheritance (which we discussed previously that we want to avoid)
- boolean (hard/soft) or a string (hard/soft) - new blending functions other than the ones provided would need if statements in the current shaders which might get messy.
Also added a `flat_shading` function and a `FlatShader` - I could make this into a tutorial as it was really easy to add a new shader and it might be a nice showcase.
NOTE: There are a few more places where the naming will need to change (e.g the tutorials) but I wanted to reach a consensus on this before changing it everywhere.
Reviewed By: jcjohnson
Differential Revision: D19761036
fbshipit-source-id: f972f6530c7f66dc5550b0284c191abc4a7f6fc4
