Tutorial example 'fit_textured_mesh' doesn't seem to work on Colab

[ricklentz]

If you do not know the root cause of the problem / bug and wish someone to help you, please
post according to this template:

🐛 Bugs / Unexpected behaviors

The tutorial doesn't present a working example. The example's error increases exponentially vs. converging to zero. No resultant mesh is visible next to the benchmark when the code has finished running.

Instructions To Reproduce the Issue:

Load the fit_textured_mesh.ipynb example in Colab and run all blocks. Observe error in block:
" We initialize the source shape to be a sphere of radius 1.
src_mesh = ico_sphere(4, device)"
UserWarning: floor_divide is deprecated and will be removed in a future version of PyTorch. It currently rounds toward 0 (like the 'trunc' function NOT 'floor'). This results in incorrect rounding for negative values.

Observe the error going up to infinity

Observe no resultant solution mesh is displayed next to the benchmark mesh.

[bottler]

I think this problem (which you are observing in the new version 0.5.0) is the same as issue #561 (observed in 0.4.0). It should be fixed if you add perspective_correct=False to every RasterizationSettings in the notebook.

[ricklentz]

@Bitt

I think this problem (which you are observing in the new version 0.5.0) is the same as for issue #561 (observed in 0.4.0). It should be fixed if you add perspective_correct=False to every RasterizationSettings in the notebook.

Thank you. I've submitted a PR after successfully testing the tutorial example with the additional parameters: https://github.com/facebookresearch/pytorch3d/pull/792/commits

I could use guidance on helping the PR test results clear checks. Please let me know if there is anything I can do on my end. Thank you again!

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[ricklentz]

I submitted a PR 42 days ago (August 5th) to fix this issue for others. Should the issue stay in open status to help others until the PR is merged?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[ricklentz]

@bottler Anything I can do to move the associated PR forward?

[bottler]

We really want to understand where the nan comes from in the rasterizer (see more recent comment on #561). We are a bit resistant to patching over the problem instead of fixing it.

[ricklentz]

@bottler @nikhilaravi, @gkioxari I believe I found the bug in the rasterizer that is causing the NaN issue #561. The technical issue is a divide by zero. When perspective_correct=True, BarycentricPerspectiveCorrectionForward and BarycentricPerspectiveCorrectionBackward in ../csrc/utils/geometry_utils.cuh are called. The denominator values should not be allowed to go to zero. I completed local testing and have submitted #891 for review. :-)