Summary: Do not create output files with invalid inputs to `save_{obj,ply}()`.
Reviewed By: bottler
Differential Revision: D20720282
fbshipit-source-id: 3b611a10da6f6eecacab2a1900bf16f89e2000aa
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: CPU-only builds should be fixed by this change
Reviewed By: nikhilaravi
Differential Revision: D20598014
fbshipit-source-id: df098ec4c6c93d38515172805fe57cac7463c506
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: Add pattern linter for PyTorch3D and SlowFast, this will suggest typo fixes whenever the wrong case is accidentally used.
Reviewed By: wanyenlo
Differential Revision: D20498696
fbshipit-source-id: 1a3f4702bd0dbe06e81d0f301b3ea38ea62e7885
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: Use a consistent case for PyTorch3D (matching the logo...): replace all occurrences of PyTorch3d with PyTorch3D across the codebase (including documentation and notebooks)
Reviewed By: wanyenlo, gkioxari
Differential Revision: D20427546
fbshipit-source-id: 8c7697f51434c51e99b7fe271935932c72a1d9b9
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: Comments were describing squared distance as absolute distance in a few places.
Reviewed By: nikhilaravi
Differential Revision: D20426020
fbshipit-source-id: 009946867c4a98f61f5ce7158542d41e22bf8346
Summary: Add utility function to tesselate a torus, to be used in more complex mesh I/O benchmarks
Reviewed By: bottler
Differential Revision: D20390724
fbshipit-source-id: 882bbbe9cac81cf340a34495b9aa66e3c1ddeebc
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:
Applying the changes added for mesh rasterization to ensure that +Y is up and +X is left so that the coordinate system is right handed.
Also updated the diagram in the docs to indicate that (0,0) is in the top left hand corner.
Reviewed By: gkioxari
Differential Revision: D20394849
fbshipit-source-id: cfb7c79090eb1f55ad38b92327a74a70a8dc541e
Summary:
Update the point cloud rasterizer to:
- use the pointcloud datastructure (rebased on top of D19791851.)
- support rasterization of heterogeneous point clouds in the same way as with Meshes.
The main changes to the API will be as follows:
- The input to `rasterize_points` will be a `Pointclouds` object instead of a tensor. This will be easy to update e.g.
```
points = torch.randn(N, P, 3)
idx2, zbuf2, dists2 = rasterize_points(points, image_size, radius, points_per_pixel)
points = torch.randn(N, P, 3)
pointclouds = Pointclouds(points=points)
idx2, zbuf2, dists2 = rasterize_points(pointclouds, image_size, radius, points_per_pixel)
```
- The indices output from rasterization will now refer to points in `poinclouds.points_packed()`.
This may require some changes to the functions which consume the outputs of rasterization if they were previously
assuming that the indices ranged from 0 to P where P is the number of points in each pointcloud.
Making this change now so that Olivia can update her PR accordingly.
Reviewed By: gkioxari
Differential Revision: D20088651
fbshipit-source-id: 833ed659909712bcbbb6a50e2ec0189839f0413a
Summary: When the error occurs, another exception is thrown when tensor shape is passed to the % formatting. I have found all entries for `msg %` and fixed potential failures
Reviewed By: nikhilaravi
Differential Revision: D20386511
fbshipit-source-id: c05413eb4867cab1ddc9615dffbd0ebd3adfcaf9
Summary: Make Meshes.__getitem__ carry texture information to the new mesh.
Reviewed By: gkioxari
Differential Revision: D20283976
fbshipit-source-id: d9ee0580c11ac5b4384df9d8158a07e6eb8d00fe
Summary: Bumping the version number to 0.1.1 and thereby documenting all the places where the version number currently appears in the code.
Reviewed By: nikhilaravi
Differential Revision: D20067382
fbshipit-source-id: 76a25ed1d4036f51357e4ae3e0f07de32ad114ae
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:
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:
`PointLineDistanceForward()` should return squared distance. However, it seems that it returned non-squared distance when `v0` was near by `v1` in CPU implementation.
Pull Request resolved: https://github.com/facebookresearch/pytorch3d/pull/83
Reviewed By: bottler
Differential Revision: D20097181
Pulled By: nikhilaravi
fbshipit-source-id: 7ea851c0837ab89364e42d283c999df21ff5ff02
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:
Fixed a few MSVC compiler (visual studio 2019, MSVC 19.16.27034) compatibility issues
1. Replaced long with int64_t. aten::data_ptr\<long\> is not supported in MSVC
2. pytorch3d/csrc/rasterize_points/rasterize_points_cpu.cpp, inline function is not correctly recognized by MSVC.
3. pytorch3d/csrc/rasterize_meshes/geometry_utils.cuh
const auto kEpsilon = 1e-30;
MSVC does not compile this const into both host and device, change to a MACRO.
4. pytorch3d/csrc/rasterize_meshes/geometry_utils.cuh,
const float area2 = pow(area, 2.0);
2.0 is considered as double by MSVC and raised an error
5. pytorch3d/csrc/rasterize_points/rasterize_points_cpu.cpp
std::tuple<torch::Tensor, torch::Tensor> RasterizePointsCoarseCpu() return type does not match the declaration in rasterize_points_cpu.h.
Pull Request resolved: https://github.com/facebookresearch/pytorch3d/pull/9
Reviewed By: nikhilaravi
Differential Revision: D19986567
Pulled By: yuanluxu
fbshipit-source-id: f4d98525d088c99c513b85193db6f0fc69c7f017
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
Summary: Fixed the rotation matrices generated by the RotateAxisAngle class and updated the tests. Added documentation for Transforms3d to clarify the conventions.
Reviewed By: gkioxari
Differential Revision: D19912903
fbshipit-source-id: c64926ce4e1381b145811557c32b73663d6d92d1
Summary:
pybind now seems to need C++17 on a mac, so advise people to use it. (Also delete an unused variable to silence a warning I got on a mac build.)
Reported in github issue #68.
Reviewed By: nikhilaravi
Differential Revision: D19970512
fbshipit-source-id: f9be20c8ed425bd6ba8d009a7d62dad658dccdb1
