AABB boundary of a round cone
Forgive me if I'm completely wrong here, but isn't calculating a AABB from a cone with hemisphere (aka icecream), as simple as:
// position - cone tip
// direction - cone normal
// length - length of cone in direction of normal
// radius - radius of cone at base (radius of hemisphere)
float3 end = position + direction * length;
float3 min = end - radius;
float3 max = end + radius;
min = Min(min, position); // Minimum component-by-component of a float3
max = Max(max, position); // Maximum component-by-component of a float3
// position - cone tip
// direction - cone normal
// length - length of cone in direction of normal
// radius - radius of cone at base (radius of hemisphere)
float3 end = position + direction * length;
float3 min = end - radius;
float3 max = end + radius;
min = Min(min, position); // Minimum component-by-component of a float3
max = Max(max, position); // Maximum component-by-component of a float3
Quote:Original post by hogwashI assume 'float3' is a 3D vector type? If so, the above expressions represent a subtraction of a scalar from a point, which doesn't make sense.
float3 min = end - radius;
float3 max = end + radius;
Quote:Original post by jykQuote:Original post by hogwashI assume 'float3' is a 3D vector type? If so, the above expressions represent a subtraction of a scalar from a point, which doesn't make sense.
float3 min = end - radius;
float3 max = end + radius;
Sorry for the confusion, I should have been more clear there. My math library has the above operators defined.
Change to:
float3 v3Radius(radius, radius, radius);
float3 min = end - v3Radius;
float3 max = end + v3Radius;
... for clarity.
Am I right?
Quote:Original post by hogwashIf your math library defines addition and subtraction between a vector and a scalar, then (IMO) you should fix your math library :)Quote:Original post by jykQuote:Original post by hogwashI assume 'float3' is a 3D vector type? If so, the above expressions represent a subtraction of a scalar from a point, which doesn't make sense.
float3 min = end - radius;
float3 max = end + radius;
Sorry for the confusion, I should have been more clear there. My math library has the above operators defined.
Change to:
float3 v3Radius(radius, radius, radius);
float3 min = end - v3Radius;
float3 max = end + v3Radius;
... for clarity.
Am I right?
As for the proposed algorithm, I'm pretty sure it will fail given certain parameters for the cone (e.g. a high radius-to-height ratio).
Well that's obviously a matter of opinion ;-)
It doesn't adhere to mathematical semantics, but it saves having to construct a vector for the rhs value.
We are making games right? :-)
It doesn't adhere to mathematical semantics, but it saves having to construct a vector for the rhs value.
We are making games right? :-)
You are right about my algorithm breaking down however. I am assuming a sphere on the end of the cone rather than a hemisphere.
Cheers,
Tom.
Cheers,
Tom.
Quote:Original post by hogwashI suppose so :-)
Well that's obviously a matter of opinion ;-)
Quote:It doesn't adhere to mathematical semantics, but it saves having to construct a vector for the rhs value.Hm :-| If you're referring to performance, it seems unlikely that you would encounter this particular case often enough in practice for it to make any difference. If you're referring to less typing, then you're saving a little effort at the expense of proper semantics, which doesn't seem like a good trade to me.
Quote:We are making games right? :-)Even in game programming I would say that expressiveness, correctness, and clarity of intent are more important than saving a few keystrokes or cycles here and there.
But as you said, it is a matter of opinion :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
