SPON_viewVector v1.0.0 (READY)

[Spooner]

SPON_viewVector v1.0.0
- Released: 2008-07-07
- SQF function in a single file.
- Includes simple test mission.

Description
Calculates the direction that the local player (camera) is looking in. That is, it always points at the centre of the screen, regardless of floating zone, weapon, scope, vehicle, freelook, rear-view mirror, etc.

The view direction is distinct from getDir, which is the direction of overall facing, or from weaponDirection, which is the way the weapon is pointing.

I needed this for myself and thought someone else might find it useful. It is functionality that I've wanted in the game for a long time, but I had an epiphany today and got it worked out! Haven't tested it thoroughly yet, but it seems to work perfectly.

Parameters:
    None.

Returns:
    Normal vector of current camera view [3 element array [X, Y, Z]].

[Mr.Peanut]

Ahahaha! Nice trick! So camera coordinates are [x, z, y] format?

[Spooner]

Seem to be! I got a bit confused about the results for a while before I remembered that particular fact...

[Mr.Peanut]

Now if only we could find a way to get the exact origin of the view vector. Ah, yet more functions BI could have given us. You could find the origin if it always intersected the same LOD, but this would be impossible with vehicles.

[Spooner]

You can, since it is:

Code: [Select]

_origin = positionCameraToWorld [0, 0, 0];

I use this as the origin in the updated version that I included in SPON Map v0.3.1. I just haven't got around to updating the individual function yet (oops - oh look, it is done now!).

Updated: v1.0.0
* Used the correct visual position of the camera, rather than player position to calculate the origin of the vector.

[Denisko-Redisko]

Great!
The code has a small misprint:

Code: [Select]

private ["_position", "_viewPos", "_azimuth"]; // <-- "_azimuth", must be "_vector", and where _magnitude?


[Spooner]

Well spotted! Well, SPON_viewVector is moving into SPON Core (where it will become SPON_viewVectorDir and SPON_viewVectorUp) so I won't bother updating it here, where it will soon be deprecated.

(tracker: bug #920)

[Denisko-Redisko]

because the length of the vector is known, I think, apparently, it can be simplified:

Code: [Select]

// #include "\lib\common"
#define x(a)        ((a) select 0)
#define y(a)        ((a) select 1)
#define z(a)        ((a) select 2)

funcViewportVector = {

    private ["_viewport", "_target"];

    // Find the location of the player camera's position.
    _viewport = positionCameraToWorld [0, 0, 0];

    // Find a position very far ahead of the camera that the player is using.
    _target = positionCameraToWorld [0, 0, 1e+8];

    [
        (x(_target) - x(_viewport)) * 1e-8,
        (y(_target) - y(_viewport)) * 1e-8,
        (z(_target) - z(_viewport)) * 1e-8
    ]
};


[Worldeater]

Wouldn't it be even simpler to set the length of the vector to one? According to my understanding of floats it should also make the result more accurate.

[DeanosBeano]

very nice indeed ,
   Much better than what i was using for turrets on planes, i hope they still leave enough "cpu time" in arma2 so we can see if the engine can keep up with a speeding plane , unfourtanetly in arma it always fires out of its arse because the engine simply cant keep up.
   Just one thing though and i had problem of this too you have the azimuth which i can use to animate the turret
 but the y axis (up  down ) has always been somewhat of a git to find, i simply winged it to be honest (yup pun)
 is there a possibly to get that angle in the format you have for the azimut return ?

 

[Denisko-Redisko]

Wouldn't it be even simpler to set the length of the vector to one? According to my understanding of floats it should also make the result more accurate.

Oh, yes! This is a naive approach - use large numbers of))
This is really nice, just use the unit vector.

Code: [Select]

funcViewportVector = {
    private ["_viewport", "_target"];
    _viewport = positionCameraToWorld [0, 0, 0];
    _target = positionCameraToWorld [0, 0, 1];
    [
        x(_target) - x(_viewport),
        y(_target) - y(_viewport),
        z(_target) - z(_viewport)
    ]
};

Hmm, the previous code made the difference with the original SPON_viewVector in the 7-8 digit (position), and now the result often looks like this:

SPON_viewVector: [-0.896762,-0.435309,0.0795197]
ViewportVector:  [-0.896729,-0.435303,0.16713]

What is wrong?

[Spooner]

At a guess you've either removed (or introduced) a rounding error. Sure I had a reason to use a "long" vector and shorten it, but frankly I don't remember what I was thinking and can't be bothered thinking again right now 

Easy way is to just compare the two different viewVectors with weaponDirection of the player's primaryWeapon (assuming that the player is using his primary weapon, of course) and see which is the closest, because that should be the one that is correct.

[Worldeater]

What is wrong?

The length of the second vector. It's not normalized. Sigh, fun with floats [1] [2].

If you compare the azimuth of both versions with the "getDir player" you'll see that the original solution matches it exactly (up to the last digit), whereas the "length one solution" is slightly off.


[1] As in: hint str(1.333 + 1.225 - 1.333 - 1.225);
[2] I think I'll have to read Goldberg's "What Every Computer Scientist Should Know About Floating-Point Arithmetic" once more.

[Spooner]

Ah, something I forgot to mention when comparing view vector with weapon direction is that you can't have floating zone enabled for this to work. Still, this azimuth comparison should be reasonably conclusive (believe me when I say I spent time on this function, however simple, back in the day, so apart from inefficiency it seems to work correctly ).

[Denisko-Redisko]

[2] I think I'll have to read Goldberg's "What Every Computer Scientist Should Know About Floating-Point Arithmetic" once more.

Oh, spare me! In my understanding, the size of numbers (digit, sorry, I am very bad speak english) is not so important as their remoteness, for example:
1e9 + 1e-9 == 1e9.
1e9 + 1e+9 == 2e9
Maybe I do not understand your advice:

Wouldn't it be even simpler to set the length of the vector to one? According to my understanding of floats it should also make the result more accurate.

Whatever sqf-code you suggested?

PS.

In principle, all right. To have a sufficient accuracy the number should be proportional. But (for example), 20000 (x-coordinate of the player's camera), and 1 very different to the calculation gave a good accuracy.
Removed