koobas.hobune.stream
Help with gun accuracy in degrees.
I want to add inaccuracy to fired bullets. I've been using the typical method that adds a randomized vector3 by the velocity vector3 of the bullet. This is fine for a quick and dirty solution, but falls short in a number of areas.
1) As velocity increases, so too does the accuracy. This is bad.
2) The "gun accuracy" value gives no good face value meaning without extensive trial and error.
3) The bullet doesn't actually face in the direction of movement.
So, I'm trying to construct an inaccuracy system that allows me to define gun accuracy in a simple degree notation.
e.g. If a gun has an accuracy value of 5, then the shot will fire up to 5 degrees off from the the barrel line. Or within a cone with radius of 5.
var accuracy : float;
var error : Vector2 = Random.insideUnitCircle * accuracy;
var errorRotation : Quaternion = Quaternion.Euler(error.x, error.y, 0);
var bullet : GameObject = Instantiate( prefab, transform.position,
transform.rotation * errorRotation);
Random.insideUnitCircle gives me a random value of -1 to 1 in each direction (but only in a circle area) So multiplying by the accuracy value should give me a random point in a circle with accuracy as the radius. This will represent the degrees of rotation from straight.
Quaternion.Euler() should then convert those degree values into a rotation.
So, multiplying the gun rotation by the errorRotation should give me something within that cone I'm looking for, right?
Except it doesn't.
Even with accuracy of 1, bullets fly everywhere, not in a 1 degree cone.
With an accuracy of 0, the bullets fly straight with no error.
What am I doing wrong here?
Did you try adding them ins$$anonymous$$d of multiplying them? I mean
var bullet : GameObject = Instantiate( prefab, transform.position,
Quaternion.Euler (transform.rotation.eulerAngles + errorRotation.eulerAngles));
1) As velocity increases, so too does the accuracy. This is bad.
No :). You have to calculate this with normalized values.
Vector3 inacVelocity = (velocity.normalized + someRandomVector).normalized * velocity.magnitude;
Well, it looks like my original code is correct.
I believe something was changing the result later. In addition, Unity was doing some strange things that disappeared when I restarted it.
For the bullet facing direction, you can use the LookAt method from the bullet's transform.
You can set it as the following to achieve what you want.
var accuracy : float;
var error : Vector2 = Random.insideUnitCircle * accuracy;
var bullet : GameObject = Instantiate( prefab, transform.position, Quaternion.identity);
bullet.transform.LookAt(transform.forward + (transform.right * error.x) + (transform.up * error.y));
For a much faster method, that is also keeps working at high angles (up to 360 degrees), while also being perfectly uniform, you can use this:
public static Vector3 GetRandomUniformVectorInCone(float radius)
{
//http://math.stackexchange.com/questions/56784/generate-a-random-direction-within-a-cone
//The 2 - sphere is unique in that slices of equal height have equal surface area
//That is, to sample points on the unit sphere uniformly, you can sample z uniformly on[−1, 1] and ϕ uniformly on[0, 2π).
//If your cone were centred around the north pole, the angle θ would define a minimal z coordinate cosθ,
//and you could sample z uniformly on[cosθ, 1] and ϕ uniformly on[0, 2π) to obtain the vector
//(sqrt(1 - z^2) * cosϕ, sqrt(1 - z^2) * sinϕ, z)
float radradius = radius * Mathf.PI / 360;
float z = Random.Range(Mathf.Cos(radradius), 1);
float t = Random.Range(0, Mathf.PI * 2);
return new Vector3(Mathf.Sqrt(1 - z * z) * Mathf.Cos(t), Mathf.Sqrt(1 - z * z) * Mathf.Sin(t), z);
}
The source is, as stated, this problem: http://math.stackexchange.com/questions/56784/generate-a-random-direction-within-a-cone
Simply multiply the resulting vector by your direction quaternion, and everything will work fine.
I'm confused as to why this would be "much faster", when you've got two Sqrt(), two Cos(), a Sin(), and a divide operator, all above what's in the original code. And all of which I believe are slower than anything else in the original. I know Sqrt() is slow, and I'm assu$$anonymous$$g the trig is slow as well.
At any rate, the original code works fine. As noted, something else was causing the problem. (FWIW, using insideUnitSphere is also an option to produce bias in a manner more relevant to weapons - where the distribution tends to cluster closer the center.)
But your comment got me to thinking about distribution. You are correct in that the distribution isn't always uniform.
While insideUnitCircle does prevent the rotation from producing a square distribution at smaller angles, I can see how the results would get skewed as angle increases.
So I did a test where I could see the resulting shots in a sphere-like pattern.
Up to 45° I can see no real discernible gaps or bias. (Though it's possible a smaller shot size might reveal some shortfall in places at the edges, it wasn't visible in my tests.)
At 90° you can see some areas that can't be reached in a sort of shallow curve between the when approaching the edge.
Around 120° the edge pattern is a bit weird, as 2 bulges are for$$anonymous$$g where x approaches 0, and y approaches -1 and 1.
Then out to 180° the shortfall seems to disappear. $$anonymous$$y intuition told me to expect the unreachable gaps to get larger, but they don't appear to. Ins$$anonymous$$d, they are folding in on themselves when x approaches 0, and y approaches -1 and 1. This is closing the gaps, but creating some bias.
Anything beyond 180° in this context is meaningless.
TL;DR: The code is fine for the typical range of inaccuracy as used for weapons. For larger angles, there can be gaps and bias, but still probably unnoticeable except for the most exotic of uses.
I may have gotten carried away with "much faster", but insideUnitCircle is likely more expensive. Haven't tested it yet, but it likely uses this, which is has a whole lot of math functions. The JIT compiler does do some optimization, but I could just store ($$anonymous$$athf.Sqrt(1 - z * z)) before.
However, there is more to distribution than "can it reach this part", having cold or hot spots, which is bound to happen with non-mathematically-proven methods, will create problems, and it would be impossible to predict the likeliness to hit something if you want to do AI or an automated weapon balancing system, like many games use now.
