when checking if some object is within a certain area, which approach would have better performance if using glm library?
vec3 pos;
// Using a bounding box to represent that area
1) if ( pos.x > box.MinX && pos.x < box.MaxX
&& pos.y > box.MinY....) { // do something..}
// Using a sphere to represent that area
2) if ( glm::length ( pos - sphere.centerPosition ) <= sphere.radius ) { // do something..}
Traditionally, length computations would be avoided by the plague because of the cost of sqrt -- length(x) == sqrt(dot(x,x)) -- so you'd use the length-squared instead of length in bounding sphere tests:
d = pos - sphere.centerPosition;
if( glm::dot( d, d ) <= sphere.radius*sphere.radius ) { // do something..}
This isn't as much of an issue these days as CPU's are pretty good at floating point sqrt now, but it's still something that you should do if you're able to easily :)
I would assume that a bounding-sphere test will be slightly faster than an AABB test, but there wouldn't be too much difference between them.
if( glm::dot( d, d ) <= sphere.radius*sphere.radius ) { // do something..}
I know this is exactly the same mathematically as working out the squared length of d but is it such a good idea to use the dot product to do this? Correct me if I am wrong but it seems an unintuitive choice.
That depends on personal preference and the idioms used in the rest of your codebase. I do a lot of shader programming in my job and quite often see dot(a,a) used instead of a.x*a.x+a.y*a.y+a.z*a.z, so to me it's intuitive.
If you're using it for the first time in a project, it will be less intuitive to a future reader, so you could use the longform instead, or leave a comment. Typically in CPU math libraries, you see two functions - length and lengthSquared, which is more readable than an 'abused' dot :wink:
Performance-wise, it shouldn't make a difference as long as you trust your compiler... but if you're on a platform with a native dot instruction and a dot intrinsic, then the dot version would be create the best chance for the compiler to emit that instruction.
The 2 methods are not equivalent, because a box is not a sphere. Therefore, whatever your "certain area" is, it can only be correctly represented by one of those 2 methods.
Of course the two methods are not the same. But in this case I don't care about the exact dimension of the area.
I'd say go for what you think does it for you with readable/ understandable code.
if performance becomes an issue, you can profile and change it (which I don't expect for this case).
readable/ understandable code.
and change it (which I don't expect for this case).
What do those things mean?
I think that Kylotan is right - you could choose which one better fits your area.
He didn't say anything about I could choose which one better fits my area. He merely thought I couldn't represent a sphere with a cube, and I think anyone knows that.
