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.
Hopefully everyone does, which is why you need to reframe your problem. (And probably also stop stressing about micro-optimisations.)
Everyone also knows that spheres and boxes are common bounding shapes for objects that are neither boxes of spheres. Saying that a thing "can only be correctly represented by one of those 2 methods", when "everyone" knows that approximate bounding shapes are a thing, is not helpful or constructive...Hopefully everyone does, which is why you need to reframe your problem. (And probably also stop stressing about micro-optimisations.)
Many current coders originate from 1997, and make tutorials explaining performance issues, and ways to organize things to make it run faster. We do that here in the forum too. Pick a non-standard choice in data structures, and very likely someone wil speak about performance implications of that choice.
We send out loads of messages about being very aware of performance. New users pick that up, and are aware of, and working on performant code, even if the final difference in performance is not noticable in the final result.
The original question asked about "within a certain area". If that area can be represented by a box or a sphere then it is not "certain"!
The fact that this is a pointless micro-optimization is a completely separate and orthogonal point. You could have made it without trying to interpret something into the OP which was not really there.A large proportion of posts on this forum are strangely fixated with these little micro-optimisations as if it's still 1997, but in practice I don't see anyone else seriously considering ditching a cube collider in favour of a sphere collider (or vice versa) for performance reasons. Pick the volume that most closely matches the actual problem.
I don't know, it seems like a fair point to at least address in Beginners, where you can't easily tell what knowledge base the poster has.
Even if it doesn't seem to be the case here, it wouldn't be the first time where people ask for something and don't fully understand the consequence of either choice.
I don't know, it seems like a fair point to at least address in Beginners, where you can't easily tell what knowledge base the poster has.
Even if it doesn't seem to be the case here, it wouldn't be the first time where people ask for something and don't fully understand the consequence of either choice.
The fact that this is a pointless micro-optimization....
Depends really.
If you're doing 10s, 100s or 1000s of these per frame it's certainly a pointless micro-optimization. Just pick the technique that fits your data best. If you're doing tens of millions or hundreds of millions of them per frame it's no longer a micro-optimization; it's no probably no longer even an optimization but a core requirement in order to get acceptable performance.
This topic has been locked by a moderator. New replies are not allowed.
GameDev.net uses cookies to ensure you have the best experience on our platform. Learn more
