Not transforming to voxel space when lifting and unclarities about the near_plane parameter
NSavov opened this issue · 1 comments
First of all, thank you for your outstanding work.
There are a few issues that I would like to clear up, as I am having trouble getting good results with new data:
- Why is the translation of the frustum bounds to the barycenter switched off while lifting?
When computing the frustum bounds while lifting, in 'compute_frustum_bounds()', I find the following code:
# Transform to grid coordinates (grid at origin)
pl = torch.round(torch.bmm(world_to_grid.repeat(8, 1, 1), torch.floor(p)))
pu = torch.round(torch.bmm(world_to_grid.repeat(8, 1, 1), torch.ceil(p)))
pl = torch.round(torch.floor(p))
pu = torch.round(torch.ceil(p))
The grid coordinates with which we intersect later are translated but not the boundaries.
- What is the role of the near_plane parameter in the intrinsics file and how should it be chosen?
It seems that it is only used for projection, while otherwise a separate opt.near_plane parameter is used. Moreover, it is not used to clip the visible field (as the concept of near plane is) but to translate the points. It is unclear why this is necessary for projection and how to select a value of this parameter and opt.near_plane.
Hi,
thanks for the feedback!
Why is the translation of the frustum bounds to the barycenter switched off while lifting?
Nice catch! This is not intended. I fixed it.
What is the role of the near_plane parameter in the intrinsics file and how should it be chosen?
This parameter sets the near plane of the frustrum. It is only relevant for any real-world scenes that don't lie in the unit cube. If the near_plane is unspecified (0.0) in the calibration file, the command-line input was supposed to be used (which defaults to sqrt(3)/2 if unspecified), which is optimal for objects that are scaled to lie in the unit cube. However, there was a bug here where the command line was always passed. Thanks for catching, I fixed it!
Hope this clarifies things.