• Create Account

We're offering banner ads on our site from just \$5!

# Collision detection with scaled spheres :(

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

4 replies to this topic

### #1bwhiting  Members   -  Reputation: 787

Like
0Likes
Like

Posted 12 July 2013 - 09:46 AM

A quick question for you collision detection gurus:

How do you handle sphere vs triangle mesh collision detection when the mesh is scaled dis-proportionately?

i.e. a sphere vs a mesh with a scale of (1,0.5,1.25).

When scales are uniform it is easy to just transform the center of the sphere by inverse world matrix of the mesh then scale the radius by the inverse scale. But when the scales are out, I am not sure what to do.

What is the usual response here, ban scaling unless proportional? Or is the solution really simple but something I haven't thought of yet.

Cheers, and apologies if this is a really idiotic question.

### #2Krohm  Crossbones+   -  Reputation: 3175

Like
0Likes
Like

Posted 12 July 2013 - 11:58 AM

It's a very good question instead!

Last time I checked even Bullet appeared to have some different ideas about that, I think there was a "scaling object" of some sort... but I'm just taking it out of my memory and I haven't checked the documentation in a while.

Personally I re-scale everything at baking time. And if scaling happens at runtime... I am going to have a problem!

### #3Álvaro  Crossbones+   -  Reputation: 13661

Like
0Likes
Like

Posted 12 July 2013 - 12:06 PM

Let me first make sure I understand the issue. Let's start with the solution you have when only uniform scaling is involved: You seem to be transforming the sphere to the model coordinates of the mesh and then computing the intersection there. If you were to do that in a situation where the mapping from model coordinates to world coordinates involves a non-uniform scaling, the sphere in model coordinates is now an ellipsoid, and the intersection test is harder.

Is that what you are talking about? If it is, you can compute the intersection between an ellipsoid and a mesh by first transforming both objects through an affine mapping that turns the ellipsoid into a sphere and then computing the intersection there. Of course, the model-to-world mapping is an example of such a transformation. So you can just compute the intersection in world coordinates instead of model coordinates.

Does that make sense? It feels like I must have missed something...

### #4bwhiting  Members   -  Reputation: 787

Like
0Likes
Like

Posted 12 July 2013 - 12:23 PM

Thanks for the replies guys,

Yes that does sound like a solution that would work but I wanted to avoid having to transform the meshes vertices to save time, i.e only every transform the sphere, I guess that means ellipsoid detection is the way to go :S although I don't like the idea of rotations here.

Maybe the best bet is check the scale, if uniform, move sphere into mesh space, if not move mesh into world space. Means I can at least re use the collision detection code. The downside that also comes with transforming the mesh into world space is I would also have to transform my "collisionData" too; I cache the triangle's plane and the plans of its edges for faster detection.

Shame there doesn't seem to be a catch all solution that reduces the need to transform the meshes vertices.

### #5Krohm  Crossbones+   -  Reputation: 3175

Like
0Likes
Like

Posted 13 July 2013 - 12:19 AM

Maybe you could transform the hit vector instead. I mean, the part of the hit vector which is inside the broadphase volume. I think I've seen something like that in Bullet source.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS