collider.extents in the forward directon

I hope someone can help me with the following problem:

If I have a flat disc traveling at rigidbody.velocity with a rigidbody.rotation, how would I figure the collider.extents of the leading edge?

I have a script that checks to make sure a very small projectile traveling at a very high velocity does not pass through any meshes without impacting. The scripts works great, but I'm using the value of the shortest axis as part of the script.

To be extremely accurate, I'd really like to feed the collider.extents of the forward edge of the collider given it's rotation and velocity.

Any thoughts?

Thanks for any help.

Mitch

 

I wasn't really thinking at all when I used collider.extents, sorry...if you look up the docs on it, it becomes obvious why it's not really suitable in this case. My only excuse is that I was using it for something else (where it actually makes sense) and just kept going with it.

I'll try to think of something that would work, if somebody else doesn't first.

--Eric

 

I've been reading the docs and experimenting - the collider.extents seem to change value as you rotate the transform. I'm trying to figure out what the changing values actually reflect.

Also, I'm trying to wrap my head around the difference between collider.extents and collider.bounds.extents.

Fun stuff.

As always, thanks for your input, Eric. Much appreciated. You really helped me in a huge way with the physics issue (small/fast projectiles).

Still hope someone can suggest some solution to determining the forward radius of the collider.

Mitch

 

An illustration might help...the blue box represents the extents. It doesn't rotate and always fully encapsulates the object. Haven't had a chance to think about your problem yet, sorry....

--Eric

 

Now I'm even more confused!

So the extents doesn't rotate with the GO - as per your illustration?

I thought it did rotate as the transform rotates - it's attached to the transform.

Try this test - create a cube - scale is 1,1,1. Attach a script that just prints(collider.bounds.extents.y);

Now run the scene and rotate the cube via the inspector - the value of extents changes as you rotate the cube from .5 at 0 degrees to .7 at 45 degrees (x axis rotation).

Which makes sense to me because the when the cube is flat on a side, the extents.y is .5 (half the scale of the cube).

But on a 45 degree angle, the edge of the cube is on the global y axis and the extents.y is now .7. (the distance from the center of the cube to an edge is greater than the distance from the center to the side.)

Anyway, been busy at work - as soon as I have a chance I have a few ideas on how to figure this out using the values of collider.extents, rigidbody.rotation and rigidbody.velocity.

Those variables will give the value of the radius of the object from the center to the edge of the object in the direction of travel.

Then that value can be used in the script to ensure that all collisions will happen for small projectiles at high velocities.

 

Extents is given in World space so it is always relative to the World axis. If it was given in local space it would rotate with the cube. Have you tried Mesh.bounds(). You use GetComponent(MeshFilter).mesh.

 

I see - thanks for the clarificaton.

I'll look into Mesh.bounds()

 

Actually I might be confusing things between collider.extents and collider.bounds.extents. The latter is what doesn't rotate, as I illustrated.

Anyway, I have something that sort of works:

Code (csharp):

1. var v = transform.InverseTransformDirection(rigidbody.velocity);
2. v.x = Mathf.Abs(v.x);
3. v.y = Mathf.Abs(v.y);
4. v.z = Mathf.Abs(v.z);
5. var p = Vector3.Project(collider.size, v);
6. var diameter = p.x + p.y + p.z;
7.  

This works perfectly as long as the object's rotation is by 90 degree intervals on any axis relative to the direction of its velocity. "diameter" becomes somewhat too large for other rotations, however. A crude work-around might be to find the longest axis and just limit "diameter" to that. I'm sure there's some simple elegant way to do this correctly in all cases with two lines of code, if only I understood this stuff....

--Eric

 

Thanks for the code snippet, Eric. I'm learning quite a bit from your responses. I appreciate the time you take to answer.

I have the script working very well as is. The shortest axis is .025 so I just set that manually - if I can perfect it with your suggestion, I will do that.

But I wanted to report a strange anomally. It seems that strange things happen to the physics engine with small objects traveling at high velocities. I couldn't understand why the puck would fall through the ice when dropped from certain heights and not others. Or dropped off to the side x=3 would collide with the ice mesh, but dropped from x=2 would pass through.

Then, on a strange hunch, I moved my rink GO from 0,0,0 to 0,1,0.

In other words I just lifted my rink up 1 meter and away from the center of the universe (0,0,0)

And low and behold, the puck never falls through the ice now! It seems that y=0 for the playing field is not so good for small objects traveling at high velocities. But y=1 is soooo much better.

Go figure.