[filters] FrustumCulling: asymmetrical Field of View #5438
Conversation
|
Have added a test that extract all.pcd, the effect is like: |
|
@mvieth I've noticed that formatting check would not be done on |
Unfortunately, clang-format wasn't used in the beginning of PCL (perhaps because it didn't exist back then 😄 ). Now we slowly enforce clang-format module by module, but we can only format a module if there are no open pull requests that change files in that module. Otherwise there would be so many merge conflicts for that pull request that we can't fix them and would have to close the pull request. Currently, there are several pull requests that change files in the filters module, so it is not a good idea to format the whole filters module now. |
|
I see, that's not an easy work. |
mvieth
added
changelog: new feature
| float fp_h_d = float(2 * std::tan(vfov_rad / 2) * fp_dist_ * (roi_ymax - 0.5)); // far plane lower height | ||
| float fp_w_l = float(2 * std::tan(hfov_rad / 2) * fp_dist_ * (roi_xmin - 0.5) * (-1)); // far plane left width | ||
| float fp_w_r = float(2 * std::tan(hfov_rad / 2) * fp_dist_ * (roi_xmax - 0.5)); // far plane right width | ||
| float np_h_u = float(2 * std::tan(fov_lower_bound_rad) * np_dist_ * (roi_ymin - 0.5)); // near plane upper height |
There was a problem hiding this comment.
I just noticed something strange: np_h_u seems to be switched with np_h_d, and fp_h_u seems to be switched with fp_h_d. Then later, while computing fp_tl, fp_tr, np_br, ... (the corners), there shouldn't be any minus signs because the upper/lower height and left/right width are already signed. Could you look into this?
There was a problem hiding this comment.
Sure, but this seems another big issue, maybe dealing with it in another PR is better.
3 participants
Attemp to implement the feature mentioned in #5422