WorldToScreen

archit · 2012-11-23T10:13:26.000Z

Can anyone explain me how it works also with a sample code?

[COLOR="Black"]On a game world, coordinates are stored on a 3D Vector (x, y, z). But to make a wallhack or whatever, you need to be able to translates this 3D Coordinates to a 2D Vector so it can be displayed correctly on your screen. That's where the World2Screen go in.

In simple words, it translates a 3D Vector (usually the enemy position on the world) to a 2D Vector, the coordinates on your screen.

Sample:

Code:

bool WorldToScreen(Vector3D World, float *ScreenX, float *ScreenY)
{
    //Get the enemy position
    Vector3D Position = VectorSubtract(World, RefDef->Origin);
    Vector3D Transform;

    //Get the Dot Products from the View Angles of the player
    Transform.x = DotProduct(Position, RefDef->viewAxis[1]);
    Transform.y = DotProduct(Position, RefDef->viewAxis[2]);
    Transform.z = DotProduct(Position, RefDef->viewAxis[0]);

    //Make sure the enemy is in front of the player. If not, return.
    if (Transform.z < 0.1f)
        return false;
    
    //Calculate the center of the screen
    Vector2D Center = Vector2D((float)RefDef->Width * 0.5f, (float)RefDef->Height * 0.5f);

    //Calculates the screen coordinates
    *ScreenX = Center.x * (1 - (Transform.x / RefDef->fov.x / Transform.z));
    *ScreenY = Center.y * (1 - (Transform.y / RefDef->fov.y / Transform.z));
    
    return true;
}

Credits to attilathedud down from here

Full and long tutorial

Before I start, I would like to put forth that I would count Math amoungst my worst subjects - and Geometry amoungst my worst fields in Math. This partially has to do with the fact I took Geometry back when I was in eight-grade, and that, like every thirteen year-old, I was an idiot who did not care about learning. As such, there might be mistakes in the method I am about to put forth; all I know is that it works, and that to my mind, it seems correct. Feel free to mention any mistakes you find.

Consider the following scene; you are the entity marked "P," there is another entity marked "E," and there is the origin named "O:"

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img1.jpg[/IMG]

Strip away the buildings and all the fancy graphical effects, and this boils down to:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img2.jpg[/IMG]

Now knowing this, how are we to translate the entity E's position into a 2D coordinate? Well the first measure is to understand what we actually mean. There is no way to directly translate a 3D coordinate into a 2D coordinate, just as there is no way to directly translate a cube into a square; however, notice the word "directly." Let us continue with the example of a cube - there obviously has to be a way to translate a cube into a square, or at least into a 2D space, otherwise something like:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img3.png[/IMG]

would simply not be possible. So how do we go about this? Whenever we choose to draw a 3D object on a 2D plane (such as paper), we must first pick a view-port, which is exactly what it sounds like - a static view of the scene with a fixed source. To turn a cube into a square, we simply pick the view-port to be directly facing one of the sides of the cube, as so:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img4.jpg[/IMG]

To model the earlier model (the common drawing that is used to represent a cube), we simply place the view-port so that it looks directly at one of the angles:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img5.jpg[/IMG]

This same idea applies to any F.P.S.'s - in fact, it is central to the notion of them. Most modern F.P.S.'s conceive the illusion that as you move, you move your character around the map; this is simply not true. When "moving," all one is doing is adjusting their view-port in relation to the world. To track entity location then, most games make use of a series of 3D vectors that give the location of an entity relative to the origin of the map.

Knowing this, let us now go back to original representation of our scene and make it more accurate:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img6.jpg[/IMG]

If we eliminate the Y-axis in our problem (we will assume the map is constantly flat), we can take a top down view of the above image, and greatly simplify our task:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img7.jpg[/IMG]

Given that these two entities could be at any location on the map (even though we assume they are always in Quadrant I), it makes sense to stop trying to focus the scene around the map's origin, and instead makes sense to allow our entity P to be the origin - we can do this by subtracting our origin vector and the enemy's origin vector. The result will be the absolute distance of the entity E from the entity P.

Assume vAbsDistance is a three dimensional vector. Let vAbsDistance be equal to:

vAbsDistance = vEnemy - vPlayer

In relation to operations on vectors, let:

vAbsDistance.x = vEnemy.x - vPlayer.x
vAbsDistance.y = vEnemy.y - vPlayer.y [not needed right now, but we will keep it so we can add in the Y-Axis later]
vAbsDistance.z = vEnemy.z - vPlayer.z

The vector vAsbDistance will now be a vector from the origin to an object we will call E' (E prime):

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img8.jpg[/IMG]

Now let us incorporate our view-port. Most games make use of either trio of angles that represent the yaw, pitch, and roll of a player's view-port relative to some origin (usually facing directly North or South, East or West, directly above or directly below) or a trio of 3D vectors that represent the same thing, but in vector format. For us, working with vectors is the easiest way for us to complete our task - luckily, these view-angles can be translated to vectors with some math.

* Call of Duty 4 uses both of these methods; they are held in refdef->ViewAngles (a vec3_t) and refdef->ViewAxis (an array of vec3_t's) respectively. *

* A vec3_t is nothing more than float[ 3 ]. *

Imposing the vectors that represent the view-port, and assuming we are looking at the origins, we receive:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img9.jpg[/IMG]

By eliminating the fluff, and separating the vectors, we are left with two vector compliments:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img10.jpg[/IMG]

Enter the Dot Product. If we let A and B be two vectors, than the Dot Product is nothing more than ( A.x * B.x ) + ( A.y * B.y ) + ( A.z * B.z ). However, this value has some interesting attributes:

Let A and B be two vectors, and let |A| and |B| be the length of A and B respectively, and let |A| and |B| not equal 0. Then:

A . B = |A||B|cos( theta )

Where theta is the angle represented by the image below:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img11.png[/IMG]

In our current example, this will give us the value that will represent the distance E' is away from our view-vector. As such, we will take the Dot Product of both sets of vectors, and store them appropriately.

Assume vRightTransform and vForwardTransform are two floats. Let these equal:

Code:

vRightTransform = vAbsDistance . vRightView 
vForwardTransform = vAbsDistance . vForwardView

Now we quickly need to take a diversion to account for something - the Dot Product is signed operation, meaning it will work regardless of whether or not the vector is negative. Consider the case:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img12.jpg[/IMG]

In our following equation to transform our values to a 2D coordinate, we assume vForwardTransform is positive; as such, if the enemy is behind us, then our equation will give us the same value as if he was in front of us. To account for this fact, we will need to ensure that vForwardTransform is positive before continuing! Keep this in mind for later, when we code this!

We are on to the final steps - let us now consider our problem focusing on our view-port:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img13.jpg[/IMG]

In a picture I have now lost the link to, it was explained that X is equal to the result of:

[IMG]http://i133.photobucke*****m/albums/q65/attilathedud/WorldToScreen%20Pictures/img14.jpg[/IMG]

This of course can be reduced to:

Code:

X = C + [ (C * X') / (Z'* FOV) ]

We, of course, have X' and Z' as result of our operations with the Dot Product - in addition, C and FOV are held in refdef->Width / 2 and refdef->FOVx respectively. Letting centerX equal refdef->Width / 2, this becomes:

Code:

X = centerX +(( centerX * vRightTransform )/( vForwardTransform * refdef->FOVx))

As such, we have concluded our series of steps to get our 2D coordinate (in the X-Axis, at least):

Code:

vAbsDistance = vEnemy - vPlayer

vRightTransform   = vAbsDistance . vRightView 
vForwardTransform = vAbsDistance . vForwardView 

if( vForwardTransform < 0)
        return

Let centerX = refdef->Width/2

X = centerX +(( centerX * vRightTransform )/( vForwardTransform * refdef->FOVx))

Regards

WorldToScreen

Post a Reply

Similar Threads

Tags for this Thread