Page MenuHomeWildfire Games

Refactor CBoundingSphere and add tests
ClosedPublic

Authored by vladislavbelov on Jun 14 2018, 2:40 AM.

Details

Reviewers
wraitii
Group Reviewers
Restricted Owners Package(Owns No Changed Paths)
Restricted Owners Package(Owns No Changed Paths)
Commits
rP22143: Refactor CBoundingSphere and add tests
Summary

Adds forward declaration instead of the include. Fixes a bug, when a ray inside the CBoundingSphere returns false for RayIntersect. Adds const qualifier for the constant getter.

Test Plan
  1. Apply the patch and compile the game
  2. Run tests and make sure that all works

Diff Detail

Repository
rP 0 A.D. Public Repository
Lint
Lint Skipped
Unit
Unit Tests Skipped
Build Status
Buildable 6249
Build 10374: Vulcan BuildJenkins

Event Timeline

vladislavbelov created this revision.
Vulcan added a subscriber: Vulcan.Jun 14 2018, 2:45 AM

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/648/display/redirect

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/649/display/redirect

Does it really make sense to talk about 'inside' for infinite rays?

I guess the bug you are fixing is when the ray's origin is inside the sphere (I kinda suck at geometry) ? So maybe clarify 'starting inside'?

Tests pass and code seems sensible otherwise.

source/maths/BoundingSphere.h
23

<3

Does it really make sense to talk about 'inside' for infinite rays?

I guess the bug you are fixing is when the ray's origin is inside the sphere.

Yes. Because it won't be handled as intersection currently.

So maybe clarify 'starting inside'?

Do you suggest to assume that we don't have rays inside spheres, and if have then it's not the intersection, because we don't see them?

Stan added a subscriber: Stan.Jan 19 2019, 4:10 PM
Stan added inline comments.
source/maths/BoundingSphere.cpp
29

Missing spaces.

42

Return that instead.

48

Math.Square /Pow maybe ?

49

Just like the comment about the return above.

vladislavbelov marked 2 inline comments as done.Jan 19 2019, 4:14 PM
vladislavbelov added inline comments.
source/maths/BoundingSphere.cpp
42

True.

48

No, they're slower.

Stan added inline comments.Jan 19 2019, 4:27 PM
source/maths/BoundingSphere.cpp
48

Oh okay. Why do you have to compare the v.LengthSquared(), isn't there just length ? in this case you wouldn't need the multiplication at all

vladislavbelov marked an inline comment as done.Jan 19 2019, 4:34 PM
vladislavbelov added inline comments.
source/maths/BoundingSphere.cpp
48

The length of a vector is length = sqrt(x * x + y * y + z * z). So if you want to compare the length and a number, you write if (length < number). If we remove the square root (because square is usually slower than the multiplication), we use the squared length: if (x * x + y * y + z * z < number * number).

Stan added inline comments.Jan 19 2019, 4:36 PM
source/maths/BoundingSphere.cpp
48

So so squared means square rooted here not Math Pow 2 ?

vladislavbelov marked an inline comment as done.Jan 19 2019, 4:39 PM
vladislavbelov added inline comments.
source/maths/BoundingSphere.cpp
48

No, it means that the square root was removed :) Because square root of a number in square is the number.

Stan added inline comments.Jan 19 2019, 4:44 PM
source/maths/BoundingSphere.cpp
48

Oh yeah right :)

So maybe clarify 'starting inside'?

Do you suggest to assume that we don't have rays inside spheres, and if have then it's not the intersection, because we don't see them?

No I just meant an infinite ray can't be contained inside a sphere, so rather its origin is inside the sphere. Otherwise I'm OK with this patch.

vladislavbelov added a comment.EditedJan 19 2019, 6:14 PM

No I just meant an infinite ray can't be contained inside a sphere, so rather its origin is inside the sphere. Otherwise I'm OK with this patch.

Ah, I got it. Yes, you're absolutely right. The origin is inside the sphere, not the ray.

wraitii accepted this revision.Jan 19 2019, 6:18 PM

Anyways, this is a positive change.

This revision is now accepted and ready to land.Jan 19 2019, 6:18 PM
Stan added inline comments.Jan 19 2019, 6:24 PM
source/maths/BoundingSphere.cpp
49

Actually the whole function can be written

CVector3D v = m_Center - origin;
float pcLen = dir.Dot(v);

if (pcLen <= 0)
    v = (dir * pcLen) - v;
 
return v.LengthSquared() <= m_Radius * m_Radius;
vladislavbelov marked an inline comment as done.Jan 19 2019, 6:37 PM
vladislavbelov added inline comments.
source/maths/BoundingSphere.cpp
49

Yes, you're right, thank you!

lyv added a subscriber: lyv.Jan 19 2019, 7:17 PM
lyv added inline comments.
source/maths/BoundingSphere.cpp
29

I find this particular format more easy on the eye despite what the cc says. But that’s just my opinion.

source/maths/BoundingSphere.h
1

9

50

Direction “unit vector” implies “normalization”. Doesn’t it?

Stan added inline comments.Jan 19 2019, 11:22 PM
source/maths/BoundingSphere.cpp
49

Might want to make the 0 a 0.f as well :)

lyv added inline comments.Jan 20 2019, 10:09 AM
source/maths/BoundingSphere.h
50

In fact, in Vector geometry “direction” implies a unit vector too I suppose.

vladislavbelov marked an inline comment as done.Jan 20 2019, 10:40 AM
vladislavbelov added inline comments.
source/maths/BoundingSphere.h
50

Direction “unit vector” implies “normalization”. Doesn’t it?

Yes, it does. I just remind it, for someone who isn't sure :)

Stan added a comment.Feb 25 2019, 9:58 AM

Maybe you should plan changes @vladislavbelov, unless of course it is ready to commit.

This revision was automatically updated to reflect the committed changes.
vladislavbelov marked 4 inline comments as done.