Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Math: Fix Math::Intersection::sphereFrustum #482

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Squareys
Copy link
Contributor

Hi @mosra !

As per #453 (Fix sphere frustum intersection), here's the fix plus extensive tests.

I made a conscious descision to mark "touching" geometries as non-intersection. Even though mathematically, the volume is not empty, it's infinitely small and hence useless for the main use case, which will be frustum culling.

Best,
Jonathan

Signed-off-by: Squareys <squareys@googlemail.com>
@mosra mosra added this to the 2020.0b milestone Nov 17, 2020
@codecov
Copy link

codecov bot commented Nov 17, 2020

Codecov Report

Merging #482 (47e7f6b) into master (6f1f50d) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #482      +/-   ##
==========================================
- Coverage   77.12%   77.12%   -0.01%     
==========================================
  Files         415      415              
  Lines       25498    25497       -1     
==========================================
- Hits        19665    19664       -1     
  Misses       5833     5833              
Impacted Files Coverage Δ
src/Magnum/Math/Intersection.h 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6f1f50d...47e7f6b. Read the comment docs.

{0.0f, 0.0f, 1.0f, 0.0f},
{0.0f, 0.0f, -1.0f, 10.0f}};
Copy link
Owner

@mosra mosra Nov 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, so if there's multiple ways how to represent the same plane and the planes can be in any order, maybe the test could be made instanced with testing a few equivalent variants and expecting the same points get always the same result? That could harden it quite nicely.

And that could be done for all *Frustum tests -- I see you already updated planeFrustum(), so the same instancing change could be done to all.

EDIT: and while you're at it, I think including arbitrary (instanced) transformation in both the frustum planes and the points could make sense as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instanced test for permutating the plane order sounds like it would get out of hand in the test results pretty quickly, I think a loop with iteration description is probably enough?

Re the transformation: Do you mean offsetting/transforming the entire space, frustum and points, sphere's etc by a certain transform?

@mosra mosra mentioned this pull request Nov 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

2 participants