Skip to content

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

Open
Squareys wants to merge 1 commit into
mosra:masterfrom
Squareys:fix-sphere-frustum
Open

Math: Fix Math::Intersection::sphereFrustum#482
Squareys wants to merge 1 commit into
mosra:masterfrom
Squareys:fix-sphere-frustum

Conversation

@Squareys

Copy link
Copy Markdown
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

codecov Bot commented Nov 17, 2020

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.12%. Comparing base (6f1f50d) to head (47e7f6b).
⚠️ Report is 3319 commits behind head on master.

Additional details and impacted files
@@            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              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

{0.0f, 1.0f, 0.0f, 0.0f},
{0.0f, -1.0f, 0.0f, 10.0f},
{0.0f, 0.0f, 1.0f, 0.0f},
{0.0f, 0.0f, -1.0f, 10.0f}};

@mosra mosra Nov 22, 2020

Copy link
Copy Markdown
Owner

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
Copy Markdown
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