InverseTransformPoint gives 0.0.0

Unity Engine
1

I am making a script to detect the direction of incoming fire on a generic object so I can hit one of 8 sides:

[×][×][×]
[×][0][×]
[×][×][×]

It works fine most of the time, but occasionally my hitPostion is 0.0.0, and as such making it impossible to detect the direction.

This only seems to happen on small objects (f.ex a 1x1x1 cube), so what are my options here? Move the bullet position back before calculating? That seems kinda convoluted, so I hope there is a more elegant solution?

The scripts; for reference;

public void hitShip (Vector3 bulletPosition, float damage)
    {
        hitPosition = transform.InverseTransformPoint(bulletPosition);

        float limit = 0.1f ; //0.2 gives a fairly big chance of generating "center" hits, but 0.1 narrows the mid-section
        int xAxis;
        int zAxis;

        if (hitPosition.x > limit)
        {
            xAxis = 2; //right
        }
        else if (hitPosition.x < -limit)
        {
            xAxis = 0;//left
        }
        else
        {
            xAxis = 1;//center
        }

        if (hitPosition.z > limit)
        {
            zAxis = 0;//front
        }
        else if (hitPosition.z < -limit)
        {
            zAxis = 2;//back
        }
        else
        {
            zAxis = 1;//middle
        }

    Debug.Log (armorShell[xAxis,zAxis]);
2

What about using its velocity rather than its position? That way you know the angle of attack.

3

hm, yes, I though about it, but that will not be able to tell if the hit is like this:

[×][×][×] <----
[×][0][×]
[×][×][×]

or like this:

[×][×][×]
[×][0][×]
[×][×][×] <----

or is there a clever function that I am unaware of?
(I am new to this, so there probably are :wink: )

4

But those ones wouldn’t hit the center, would they? I meant to resolve the ambiguous center hits. If it’s coming from the right like that, and it hit the center, then it must have “really” hit the shielding immediately to the right of center.

If you’re using the built in collision system, you also have the exact contact point available, but it looks like you’re doing your own thing.

5

Thanks, I’ll look into contact point.
At a glance though, wouldn’t contact.point behave similarly to the bullets transform.position during OnTriggerEnter?

And, yes, the strange/inefficent/wrong things I do is mostly because I have a fairly limited knowledge of all the available functions. I googled my way to InverseTransformPoint, and I sortof made that work, but hopefully the forum can assist with how I should have solved it :slight_smile:

//edit;

To address the center hits; Perhaps I misunderstood; Are you suggesting that I only get the velocity in the event of a center hit, and leave the rest of the code as is?

6

So I figured out the problem; the bullet was moving too fast for OnTriggerEnter. I got extra unlucky that the speed I selected (20) was just in the sweetspot that sometimes it worked, and sometimes it didn’t. That made it hard to troubleshoot, but at least I learned something new. :slight_smile:

The problem is now solved (?) by letting the bullet cast a ray with a range of speed*0,02 in front of it. This ensures that fast bullets hit, and slow bullets don’t vaporize mid air.

But how will this scale? There is quite a bit of code attached to each bullet now; Should I worry that there can be 200 raycasting bullets in a scene? Is my entire approach of “intelligent” bullets a bad design choice?

7

If the issue is fast moving rigidbodies, change the “Collision Detection” from “Discrete” to “Continuous” or “Continuous Dynamic” depending on your needs. That will be way more accurate (and performant) than a raycast.

8

Thanks for the follow up.

I tried changing the collision detection. It had no effect, but as I were at the time using OnTriggerEnter that were perhaps incorrect for that use. I’ll try another variant with OnCollisionEnter.