SPG MOBILE PHONE Downloadsoftware Telecom Press M-Health

Saturday 4 August 2012

Dropbox Reports User Accounts Were Hijacked, Adds New Security Features

Dropbox Reports User Accounts Were Hijacked, Adds New Security Features: dropbox-logo
Several weeks ago, reports started to trickle out that a number of Dropbox users were under attack from spam. Since then, Dropbox has been investigating those attacks (with some help from a third-party) and today gave the first update on the progress, saying that some accounts were indeed accessed by hackers, but that it is now adding two-factor authentication and other security features to prevent further problems.
For some background: On July 17th, a number of Dropbox users begun noticing an increase in the level spam attacking their accounts. As Sarah reported at the time, the red flag appeared when users begun reporting that the email accounts receiving spam were in fact only tied to their Dropbox accounts, which indicated that the address leak had come from Dropbox itself. Many of those reports came from the company’s international users, including Germany, the U.K. and the Netherlands.
To its credit, Dropbox was quick to respond. Less than 24 hours later, in a message posted to forums, the company said they were bringing in “an outside team of experts” to back up their own security team in the investigation along with help from law enforcement. Today, we received the first round of answers.
The company (via Dropbox’s VP of Engineering, Aditya Agarwal) said in a blog post that its investigation found that the usernames and passwords were in fact stolen and were stolen from third party websites, which were then used to sign in to “a small number of Dropbox accounts.” The company did not cite numbers specifically, so it’s not clear exactly how many accounts were accessed, but the company did say that it has contacted those users and is helping them to further protect their accounts.
The company also said that one of those stolen passwords was used to access a Dropbox employee’s account, which contained a project document with user email addresses. The company believes that “this improper access is what led to the spam.” The company also apologized and said that it has “put additional controls in place to help make sure it doesn’t happen again.”
What is that going to mean?
Dropbox is taking a number of steps, which they laid out in the post. We’ve shared them below:
  • Two-factor authentication, a way to optionally require a unique code in addition to your password when signing in. (Coming in a few weeks)
  • New automated mechanisms to help identify suspicious activity. We’ll continue to add more of these over time.
  • A new pagethat lets you examine all active logins to your account.
  • In some cases, we may require you to change your password. (For example, if it’s commonly used or hasn’t been changed in a while)
Naturally, it appears that this issue is one in which both sides are somewhat culpable. On its end, Dropbox is taking steps to improve security, and meanwhile, it suggests that users consider coming up with a unique password for each website they use. Reusable passwords, again, are not your friend. As Dropbox points out, “though it’s easy to reuse the same password on different websites, this means if any one site is compromised, all your accounts are at risk.”
As to the spam controversy, the company did not say if there were any other causes behind this other than just some wayfaring miscreant, hacker-types, because the investigation is still ongoing. But keep in mind that there have been some fairly high-profile hacks and leaks recently, like the one that targeted LinkedIn back in June.
It would not be surprising to learn that Dropbox is essentially the first service to experience a ripple effect from that hack. Given that many people use the same passwords for multiple different accounts, if hackers were able to retrieve passwords from LinkedIn accounts, it wouldn’t be too difficult to gain access to Dropbox accounts.


Recommend used laptop for upgrade under $600

Recommend used laptop for upgrade under $600: Forum: What Notebook Should I Buy?
Posted By: haze10
Post Time: 08-04-2012 at 08:11 AM


Source:Google Reader

Part number for black cover before you get access to CPU and GPU

Part number for black cover before you get access to CPU and GPU: Forum: Alienware M18x
Posted By: Heihachi88
Post Time: 08-04-2012 at 07:55 AM


Source:Google Reader

Need help upgrading to 7970m m17x r2

Need help upgrading to 7970m m17x r2: Forum: Alienware M17x
Posted By: Theredninja
Post Time: 08-04-2012 at 08:25 AM


Source:Google Reader

Cg Programming/Vertex Transformations

Cg Programming/Vertex Transformations:
adapted from GLSL_Programming/Vertex_Transformations
New page
{{TOC right}}

One of the most important tasks of the vertex shader and the following stages in a [[{{FULLBOOKNAME}}/Programmable Graphics Pipeline|programmable graphics pipeline]] is the transformation of vertices of primitives (e.g. triangles) from the original coordinates (e.g. those specified in a 3D modeling tool) to screen coordinates. While programmable vertex shaders allow for many ways of transforming vertices, some transformations are usually performed in the fixed-function stages after the vertex shader. When programming a vertex shader, it is therefore particularly important to understand which transformations have to be performed in the vertex shader. These transformations are usually specified as uniform parameters and applied to the input vertex positions and normal vectors by means of matrix-vector multiplications. While this is straightforward for points and directions, it is less straightforward for normal vectors as discussed in {{Cg Programming Unity SectionRef|Applying Matrix Transformations}}.



Here, we will first present an overview of the coordinate systems and the transformations between them and then discuss individual transformations.



[[File:Camera_analogy.png|thumb|The camera analogy: 1. positioning the model, 2. positioning the camera, 3. adjusting the zoom, 4. cropping the image |350px]]

===Overview: The Camera Analogy===

It is useful to think of the whole process of transforming vertices in terms of a camera analogy as illustrated {{Hide in print|to the right}}{{Only in print|below}}. The steps and the corresponding vertex transformations are:

#positioning the model — modeling transformation

#positioning the camera — viewing transformation

#adjusting the zoom — projection transformation

#cropping the image — viewport transformation

The first three transformations are applied in the vertex shader. Then the perspective division (which might be considered part of the projection transformation) is automatically applied in the fixed-function stage after the vertex shader. The viewport transformation is also applied automatically in this fixed-function stage. While the transformations in the fixed-function stages cannot be modified, the other transformations can be replaced by other kinds of transformations than described here. It is, however, useful to know the conventional transformations since they allow to make best use of clipping and perspectively correct interpolation of varying variables.



The following overview shows the sequence of vertex transformations between various coordinate systems and includes the matrices that represent the transformations:





{|cellpadding="5px" cellspacing="0" style="text-align:center; vertical-align:center;"

|-

|colspan="3" style="width:30%; background:#d0d0ff;"|object/model coordinates

|style="width:1%; font-size:200%;" |

|style="width:69%; text-align:left;"|vertex input parameters with semantics (in particular the semantic <code>POSITION</code>)

|-

|style="width:14%;"|

|style="width:1%; text-align:right; padding:5px 0 5px 0; font-size:200%;" |↓

|colspan="3" style="width:85%; text-align:left;"|'''modeling transformation''': model matrix <math>\mathrm{M}_{\text{object}\to \text{world}}</math>

|-

|colspan="3" style="width:30%; background:#d0d0ff;"|world coordinates

|style="width:1%;font-size:200%;" |

|style="width:69%; text-align:left;"|

|-

|style="width:14%;"|

|style="width:1%; text-align:right; padding:5px 0 5px 0; font-size:200%;" |↓

|colspan="3" style="width:85%; text-align:left;"|'''viewing transformation''': view matrix <math>\mathrm{M}_{\text{world}\to \text{view}}</math>

|-

|colspan="3" style="width:30%; background:#d0d0ff;"|view/eye coordinates

|style="width:1%;font-size:200%;" |

|style="width:69%; text-align:left;"|

|-

|style="width:14%;"|

|style="width:1%; text-align:right; padding:5px 0 5px 0; font-size:200%;" |↓

|colspan="3" style="width:85%; text-align:left;"|'''projection transformation''': projection matrix <math>\mathrm{M}_\text{projection}</math>

|-

|colspan="3" style="width:30%; background:#d0d0ff;"|clip coordinates

|style="width:1%;font-size:200%; " |

|style="width:69%; text-align:left;"|vertex output parameter with semantic <code>POSITION</code>

|-

|style="width:14%;"|

|style="width:1%; text-align:right; padding:5px 0 5px 0; font-size:200%;" |↓

|colspan="3" style="width:85%; text-align:left;"|'''perspective division''' (by the w coordinate)

|-

|colspan="3" style="width:30%; background:#d0d0ff;"|normalized device coordinates

|style="width:1%;font-size:200%;" |

|style="width:69%; text-align:left;"|

|-

|style="width:14%;"|

|style="width:1%; text-align:right; padding:5px 0 5px 0; font-size:200%;" |↓

|colspan="3" style="width:85%; text-align:left;"|'''viewport transformation'''

|-

|colspan="3" style="width:30%; background:#d0d0ff;"|screen/window coordinates

|style="width:1%;font-size:200%; " |

|style="width:69%; text-align:left;"|

|}





Note that the modeling, viewing and projection transformation are applied in the vertex shader. The perspective division and the viewport transformation is applied in the fixed-function stage after the vertex shader. The next sections discuss all these transformations in detail.



===Modeling Transformation===



The modeling transformation specifies the transformation from object coordinates (also called model coordinates or local coordinates) to a common world coordinate system. Object coordinates are usually specific to each object or model and are often specified in 3D modeling tools. On the other hand, world coordinates are a common coordinate system for all objects of a scene, including light sources, 3D audio sources, etc. Since different objects have different object coordinate systems, the modeling transformations are also different; i.e., a different modeling transformation has to be applied to each object.



====Structure of the Model Matrix====

The modeling transformation can be represented by a 4×4 matrix, which we denote as the model matrix <math>\mathrm{M}_{\text{object}\to \text{world}}</math>. Its structure is:



<math>\mathrm{M}_{\text{object}\to \text{world}} = \left[ \begin{matrix}

a_{1,1} & a_{1,2} & a_{1,3} & t_1 \\

a_{2,1} & a_{2,2} & a_{2,3} & t_2 \\

a_{3,1} & a_{3,2} & a_{3,3} & t_3 \\

0 & 0 & 0 & 1

\end{matrix} \right]</math>

&nbsp;&nbsp;<math>\text{ with } \mathrm{A} = \left[ \begin{matrix}

a_{1,1} & a_{1,2} & a_{1,3} \\

a_{2,1} & a_{2,2} & a_{2,3} \\

a_{3,1} & a_{3,2} & a_{3,3}

\end{matrix} \right]</math>

&nbsp;&nbsp;<math>\text{ and } \mathbf{t} = \left[ \begin{matrix}

t_1\\

t_2\\

t_3

\end{matrix} \right]</math>



<math>\mathrm{A}</math> is a 3×3 matrix, which represents a linear transformation in 3D space. This includes any combination of rotations, scalings, and other less common linear transformations. '''t''' is a 3D vector, which represents a translation (i.e. displacement) in 3D space.

<math>\mathrm{M}_{\text{object}\to \text{world}}</math> combines <math>\mathrm{A}</math> and '''t''' in one handy 4×4 matrix. Mathematically spoken, the model matrix represents an affine transformation: a linear transformation together with a translation. In order to make this work, all three-dimensional points are represented by four-dimensional vectors with the fourth coordinate equal to 1:



<math>P = \left[ \begin{matrix}

p_1\\

p_2\\

p_3\\

1

\end{matrix} \right]</math>



When we multiply the matrix to such a point <math>P</math>, the combination of the three-dimensional linear transformation and the translation shows up in the result:



<math>\mathrm{M}_{\text{object}\to \text{world}}\;P = \left[ \begin{matrix}

a_{1,1} & a_{1,2} & a_{1,3} & t_1 \\

a_{2,1} & a_{2,2} & a_{2,3} & t_2 \\

a_{3,1} & a_{3,2} & a_{3,3} & t_3 \\

0 & 0 & 0 & 1

\end{matrix} \right]

\left[ \begin{matrix}

p_1 \\

p_2 \\

p_3 \\

1

\end{matrix} \right]

</math>

&nbsp;&nbsp;<math>= \left[ \begin{matrix}

a_{1,1} p_1 + a_{1,2} p_2 + a_{1,3} p_3 + t_1 \\

a_{2,1} p_1 + a_{2,2} p_2 + a_{2,3} p_3 + t_2 \\

a_{3,1} p_1 + a_{3,2} p_2 + a_{3,3} p_3 + t_3 \\

1

\end{matrix} \right]</math>



Apart from the fourth coordinate (which is 1 as it should be for a point), the result is equal to



<math>\mathrm{A} \left[ \begin{matrix}

p_1\\

p_2\\

p_3

\end{matrix} \right] +

\left[ \begin{matrix}

t_1\\

t_2\\

t_3

\end{matrix} \right] </math>



====Accessing the Model Matrix in a Vertex Shader====

The model matrix <math>\mathrm{M}_{\text{object}\to \text{world}}</math> can be defined as a uniform parameter such that it is available in a vertex shader. However, it is usually combined with the matrix of the viewing transformation to form the modelview matrix, which is then set as a uniform parameter. In some APIs, the matrix is available as a built-in uniform parameter. (See also {{Cg Programming Unity SectionRef|Applying Matrix Transformations}}.)



====Computing the Model Matrix====

Strictly speaking, Cg programmers don't have to worry about the computation of the model matrix since it is provided to the vertex shader in the form of a uniform parameter. In fact, render engines, scene graphs, and game engines will usually provide the model matrix; thus, the programmer of a vertex shader doesn't have to worry about computing the model matrix. In some cases, however, the model matrix has to be computed when developing graphics application.



The model matrix is usually computed by combining 4×4 matrices of elementary transformations of objects, in particular translations, rotations, and scalings. Specifically, in the case of a hierarchical scene graph, the transformations of all parent groups (parent, grandparent etc.) of an object are combined to form the model matrix. Let's look at the most important elementary transformations and their matrices.



The 4×4 matrix representing the translation by a vector '''t''' <math>= (t_1, t_2, t_3)</math> is:



<math>\mathrm{M}_{\text{translation}} = \left[ \begin{matrix}

1 & 0 & 0 & t_1 \\

0 & 1 & 0 & t_2 \\

0 & 0 & 1 & t_3 \\

0 & 0 & 0 & 1

\end{matrix} \right]</math>



The 4×4 matrix representing the scaling by a factor <math>s_x</math> along the <math>x</math> axis, <math>s_y</math> along the <math>y</math> axis, and <math>s_z</math> along the <math>z</math> axis is:



<math>\mathrm{M}_{\text{scaling}} = \left[ \begin{matrix}

s_x & 0 & 0 & 0 \\

0 & s_y & 0 & 0 \\

0 & 0 & s_z & 0 \\

0 & 0 & 0 & 1

\end{matrix} \right]</math>



The 4×4 matrix representing the rotation by an angle <math>\alpha</math> about a normalized axis <math>(x, y, z)</math> is:



<math>\mathrm{M}_{\text{rotation}} = \left[ \begin{matrix}

(1-\cos\alpha) x\,x + \cos\alpha & (1-\cos\alpha) x\,y - z \sin\alpha & (1-\cos\alpha) z\,x + y \sin\alpha & 0 \\

(1-\cos\alpha) x\,y + z \sin\alpha & (1-\cos\alpha) y\,y + \cos\alpha & (1-\cos\alpha) y\,z - x \sin\alpha & 0 \\

(1-\cos\alpha) z\,x - y \sin\alpha & (1-\cos\alpha) y\,z + x \sin\alpha & (1-\cos\alpha) z\,z + \cos\alpha & 0 \\

0 & 0 & 0 & 1

\end{matrix} \right]</math>



Special cases for rotations about particular axes can be easily derived. These are necessary, for example, to implement rotations for Euler angles. There are, however, multiple conventions for Euler angles, which won't be discussed here.



A normalized quaternion <math>(w_q, x_q, y_q, z_q)</math> corresponds to a rotation by the angle <math>2 \arccos(w_q)</math>. The direction of the rotation axis can be determined by normalizing the 3D vector <math>(x_q, y_q, z_q)</math>.



Further elementary transformations exist, but are of less interest for the computation of the model matrix. The 4×4 matrices of these or other transformations are combined by matrix products. Suppose the matrices <math>\mathrm{M}_1</math>, <math>\mathrm{M}_2</math>, and <math>\mathrm{M}_3</math> are applied to an object in this particular order. (<math>\mathrm{M}_1</math> might represent the transformation from object coordinates to the coordinate system of the parent group; <math>\mathrm{M}_2</math> the transformation from the parent group to the grandparent group; and <math>\mathrm{M}_3</math> the transformation from the grandparent group to world coordinates.) Then the combined matrix product is:



<math>\mathrm{M}_\text{combined} = \mathrm{M}_3 \mathrm{M}_2 \mathrm{M}_1\,\!</math>



Note that the order of the matrix factors is important. Also note that this matrix product should be read from the right (where vectors are multiplied) to the left, i.e. <math>\mathrm{M}_1</math> is applied first while <math>\mathrm{M}_3</math> is applied last.



[[File:Perspective view frustum.png|thumb|Illustration of the view coordinate system.|400px]]

===Viewing Transformation===



The viewing transformation corresponds to placing and orienting the camera (or the eye of an observer). However, the best way to think of the viewing transformation is that it transforms the world coordinates into the view coordinate system (also: eye coordinate system) of a camera that is placed at the origin of the coordinate system, points (by convention) to the '''negative''' <math>z</math> axis in OpenGL and to the '''positive''' <math>z</math> axis in Direct3D, and is put on the <math>x z</math> plane, i.e. the up-direction is given by the positive <math>y</math> axis.



====Accessing the View Matrix in a Vertex Shader====

Similarly to the modeling transformation, the viewing transformation is represented by a 4×4 matrix, which is called view matrix <math>\mathrm{M}_{\text{world}\to \text{view}}</math>. It can be defined as a uniform parameter for the vertex shader; however, it is usually combined with the model matrix <math>\mathrm{M}_{\text{object}\to \text{world}}</math> to form the modelview matrix <math>\mathrm{M}_{\text{object}\to \text{view}}</math>. Since the model matrix is applied first, the correct combination is:



<math>\mathrm{M}_{\text{object}\to \text{view}} = \mathrm{M}_{\text{world}\to \text{view}} \mathrm{M}_{\text{object}\to \text{world}}\,\!</math>



(See also {{Cg Programming Unity SectionRef|Applying Matrix Transformations}}.)



====Computing the View Matrix====

Analogously to the model matrix, Cg programmers don't have to worry about the computation of the view matrix since it is provided to the vertex shader in the form of a uniform parameter. However, when developing graphics applications, it is sometimes necessary to compute the view matrix.



Here, we briefly summarize how the view matrix <math>\mathrm{M}_{\text{world}\to \text{view}}</math> can be computed from the position '''t''' of the camera, the view direction '''d''', and a world-up vector '''k''' (all in world coordinates). Here we limit us to the case of the right-handed coordinate system of OpenGL where the camera points to the '''negative''' <math>z</math> axis. (There are some sign changes for Direct3D.) The steps are straightforward:



1. Compute (in world coordinates) the direction '''z''' of the <math>z</math> axis of the view coordinate system as the negative normalized '''d''' vector:



<math>\mathbf{z} = -\frac{\mathbf{d}}{|\mathbf{d}|}</math>



2. Compute (again in world coordinates) the direction '''x''' of the <math>x</math> axis of the view coordinate system by:



<math>\mathbf{x} = \frac{\mathbf{d} \times \mathbf{k}}{|\mathbf{d} \times \mathbf{k}|}</math>



3. Compute (still in world coordinates) the direction '''y''' of the <math>y</math> axis of the view coordinate system:



<math>\mathbf{y} = \mathbf{z} \times \mathbf{x}</math>



Using '''x''', '''y''', '''z''', and '''t''', the inverse view matrix <math>\mathrm{M}_{\text{view}\to \text{world}}</math> can be easily determined because this matrix maps the origin (0,0,0) to '''t''' and the unit vectors (1,0,0), (0,1,0) and (0,0,1) to '''x''', '''y,''', '''z'''. Thus, the latter vectors have to be in the columns of the matrix <math>\mathrm{M}_{\text{view}\to \text{world}}</math>:



<math>\mathrm{M}_{\text{view}\to \text{world}} = \left[ \begin{matrix}

x_1 & y_1 & z_1 & t_1 \\

x_2 & y_2 & z_2 & t_2 \\

x_3 & y_3 & z_3 & t_3 \\

0 & 0 & 0 & 1

\end{matrix} \right]</math>



However, we require the matrix <math>\mathrm{M}_{\text{world}\to \text{view}}</math>; thus, we have to compute the inverse of the matrix <math>\mathrm{M}_{\text{view}\to \text{world}}</math>. Note that the matrix <math>\mathrm{M}_\text{view→world}</math> has the form



<math>\mathrm{M}_{\text{view}\to \text{world}} =\left[ \begin{matrix}

\mathrm{R} & \mathbf{t} \\

\mathbf{0}^T & 1

\end{matrix} \right]</math>



with a 3×3 matrix <math>\mathrm{R}</math> and a 3D vector '''t'''. The inverse of such a matrix is:



<math>\mathrm{M}_{\text{view}\to \text{world}}^{-1} = \mathrm{M}_{\text{world}\to \text{view}} = \left[ \begin{matrix}

\mathrm{R}^{-1} & -\mathrm{R}^{-1}\mathbf{t} \\

\mathbf{0}^T & 1

\end{matrix} \right]</math>



Since in this particular case the matrix <math>\mathrm{R}</math> is orthogonal (because its column vectors are normalized and orthogonal to each other), the inverse of <math>\mathrm{R}</math> is just the transpose, i.e. the fourth step is to compute:



<math>\mathrm{M}_{\text{world}\to \text{view}} = \left[ \begin{matrix}

\mathrm{R}^T & -\mathrm{R}^T\mathbf{t} \\

\mathbf{0}^T & 1

\end{matrix} \right]</math>

&nbsp;&nbsp;<math>\text{with }\mathrm{R} = \left[ \begin{matrix}

x_1 & y_1 & z_1 \\

x_2 & y_2 & z_2 \\

x_3 & y_3 & z_3

\end{matrix} \right]</math>



While the derivation of this result required some knowledge of linear algebra, the resulting computation only requires basic vector and matrix operations and can be easily programmed in any common programming language.



[[File:358durer.jpg|thumb|Perspective drawing in the Renaissance: “Man drawing a lute” by Albrecht Dürer, 1525|300px]]



===Projection Transformation and Perspective Division===

First of all, the projection transformations determine the kind of projection, e.g. perspective or orthographic. Perspective projection corresponds to linear perspective with foreshortening, while orthographic projection is an orthogonal projection without foreshortening. The foreshortening is actually accomplished by the perspective division; however, all the parameters controlling the perspective projection are set in the projection transformation.



Technically spoken, the projection transformation transforms view coordinates to clip coordinates. (All parts of primitives that are outside the visible part of the scene are clipped away in clip coordinates.) It should be the last transformation that is applied to a vertex in a vertex shader before the vertex is returned in the output parameter with the semantic <code>POSITION</code>. These clip coordinates are then transformed to normalized device coordinates by the '''perspective division''', which is just a division of all coordinates by the fourth coordinate. (Normalized device coordinates are called this way because their values are between -1 and +1 for all points in the visible part of the scene.)



====Accessing the Projection Matrix in a Vertex Shader====

Similarly to the modeling transformation and the viewing transformation, the projection transformation is represented by a 4×4 matrix, which is called projection matrix <math>\mathrm{M}_\text{projection}</math>. It is usually defined as a uniform parameter for the vertex shader.



====Computing the Projection Matrix====

Analogously to the modelview matrix, Cg programmers don't have to worry about the computation of the projection matrix. However, when developing applications, it is sometimes necessary to compute the projection matrix.



Here, we present the projection matrices for three cases (all for the OpenGL convention with a camera pointing to the negative <math>z</math> axis in view coordinates):

* standard perspective projection (corresponds to the OpenGL 2.x function <code>gluPerspective</code>)

* oblique perspective projection (corresponds to the OpenGL 2.x function <code>glFrustum</code>)

* orthographic projection (corresponds to the OpenGL 2.x function <code>glOrtho</code>)



[[File:Field of view angle in view frustum.png|thumb|Illustration of the angle <math>\theta_\text{fovy}</math> specifying the field of view in ''y'' direction.|400px]]

[[File:Perspective view frustum.png|thumb|Illustration of the near and far clipping planes at <math>z = -n</math> and <math>z = -f</math>|400px]]

The '''standard perspective projection''' is characterized by

* an angle <math>\theta_\text{fovy}</math> that specifies the field of view in <math>y</math> direction as illustrated in the figure {{Hide in print|to the right}}{{Only in print|below}},

* the distance <math>n</math> to the near clipping plane and the distance <math>f</math> to the far clipping plane as illustrated in the next figure,

* the aspect ratio <math>a</math> of the width to the height of a centered rectangle on the near clipping plane.



Together with the view point and the clipping planes, this centered rectangle defines the view frustum, i.e. the region of the 3D space that is visible for the specific projection transformation. All primitives and all parts of primitives that are outside of the view frustum are clipped away. The near and front clipping planes are necessary because depth values are stored with a finite precision; thus, it is not possible to cover an infinitely large view frustum.



With the parameters <math>\theta_\text{fovy}</math>, <math>a</math>, <math>n</math>, and <math>f</math>, the projection matrix <math>\mathrm{M}_\text{projection}</math> for the perspective projection is:



<math>\mathrm{M}_{\text{projection}} = \left[ \begin{matrix}

\frac{d}{a} & 0 & 0 & 0 \\

0 & d & 0 & 0 \\

0 & 0 & \frac{n+f}{n-f} & \frac{2 n f}{n-f} \\

0 & 0 & -1 & 0

\end{matrix} \right]</math>

&nbsp;&nbsp;<math>\text{ with } d = \frac{1}{\tan(\theta_{\text{fovy}}/2)}</math>



[[File:Oblique perspective view frustum.png|thumb|Parameters for the oblique perspective projection.|400px]]

The '''oblique perspective projection''' is characterized by

* the same distances <math>n</math> and <math>f</math> to the clipping planes as in the case of the standard perspective projection,

* coordinates <math>r</math> (right), <math>l</math> (left), <math>t</math> (top), and <math>b</math> (bottom) as illustrated in the corresponding figure. These coordinates determine the position of the front rectangle of the view frustum; thus, more view frustums (e.g. off-center) can be specified than with the aspect ratio <math>a</math> and the field-of-view angle <math>\theta_\text{fovy}</math>.



Given the parameters <math>n</math>, <math>f</math>, <math>r</math>, <math>l</math>, <math>t</math>, and <math>b</math>, the projection matrix <math>\mathrm{M}_\text{projection}</math> for the oblique perspective projection is:



<math>\mathrm{M}_{\text{projection}} = \left[ \begin{matrix}

\frac{2 n}{r-l} & 0 & \frac{r+l}{r-l} & 0 \\

0 & \frac{2 n}{t-b} & \frac{t+b}{t-b} & 0 \\

0 & 0 & \frac{n+f}{n-f} & \frac{2 n f}{n-f} \\

0 & 0 & -1 & 0

\end{matrix} \right]</math>



[[File:Orthographic view frustum.png|thumb|Parameters for the orthographic projection.|350px]]

An '''orthographic projection''' without foreshortening is illustrated in the figure {{Hide in print|to the right}}{{Only in print|below}}. The parameters are the same as in the case of the oblique perspective projection; however, the view frustum (more precisely, the view volume) is now simply a box instead of a truncated pyramid.



With the parameters <math>n</math>, <math>f</math>, <math>r</math>, <math>l</math>, <math>t</math>, and <math>b</math>, the projection matrix <math>\mathrm{M}_\text{projection}</math> for the orthographic projection is:



<math>\mathrm{M}_{\text{projection}} = \left[ \begin{matrix}

\frac{2 }{r-l} & 0 & 0 & -\frac{r+l}{r-l} \\

0 & \frac{2 }{t-b} & 0 & -\frac{t+b}{t-b} \\

0 & 0 & \frac{-2}{f-n} & -\frac{f+n}{f-n} \\

0 & 0 & 0 & 1

\end{matrix} \right]</math>



[[File:Viewport transformation.png|thumb|Illustration of the viewport transformation.|400px]]



===Viewport Transformation===

The projection transformation maps view coordinates to clip coordinates, which are then mapped to normalized device coordinates by the perspective division by the fourth component of the clip coordinates. In normalized device coordinates (ndc), the view volume is always a box centered around the origin with the coordinates inside the box between -1 and +1. This box is then mapped to screen coordinates (also called window coordinates) by the viewport transformation as illustrated in the corresponding figure. The parameters for this mapping are the coordinates <math>s_x</math> and <math>s_y</math> of the lower, left corner of the viewport (the rectangle of the screen that is rendered) and its width <math>w_s</math> and height <math>h_s</math>, as well as the depths <math>n_s</math> and <math>f_s</math> of the front and near clipping planes. (These depths are between 0 and 1). In OpenGL and OpenGL ES, these parameters are set with two functions:



<code>glViewport(GLint </code><math>s_x</math><code>, GLint </code><math>s_y</math><code>,

GLsizei </code><math>w_s</math><code>, GLsizei </code><math>h_s</math><code>);</code>



<code>glDepthRangef(GLclampf </code><math>n_s</math><code>, GLclampf </code><math>f_s</math><code>);</code>



The matrix of the viewport transformation isn't very important since it is applied automatically in a fixed-function stage. However, here it is for the sake of completeness:



<math>\left[ \begin{matrix}

\frac{w_s}{2} & 0 & 0 & s_x + \frac{w_s}{2} \\

0 & \frac{h_s}{2} & 0 & s_y + \frac{h_s}{2} \\

0 & 0 & \frac{f_s - n_s}{2} & \frac{n_s+f_s}{2} \\

0 & 0 & 0 & 0

\end{matrix} \right]</math>



=== Further Reading ===

The conventional vertex transformations are also described in less detail in [http://http.developer.nvidia.com/CgTutorial/cg_tutorial_chapter04.html Chapter 4 of Nvidia's Cg Tutorial].



The conventional OpenGL transformations are described in full detail in Section 2.12 of the “OpenGL 4.1 Compatibility Profile Specification” available at the [http://www.khronos.org/opengl/ Khronos OpenGL web site]. A more accessible description of the vertex transformations is given in Chapter 3 (on viewing) of the book “OpenGL Programming Guide” by Dave Shreiner published by Addison-Wesley. (An older edition is available [http://www.glprogramming.com/red/chapter03.html online]).





{{Cg Programming BottomNav}}


Source:Google Reader

ESA_EF_2012

ESA_EF_2012: SAlES, DEmogrAphic AnD USAgE DAtA

2012

ESSEntiAl fActS
AboUt thE compUtEr AnD ViDEo gAmE inDUStry

[ iii ]

*“computer and video games have reached a critical mass. today, nearly every device with a screen plays games, providing interactive entertainment experiences for a wide and diverse population. the creativity of our developers and publishers produces an ever-expanding variety of games to choose from in different formats and across all platforms. their innovations drive consumer demand for our products, solidifying our industry’s position as one of the strongest and most cutting-edge se


Source:Google Reader

Saral Imaging 1.0.0 (Shareware)

Saral Imaging 1.0.0 (Shareware): A digital document and picture cabinet for physicians (read more)


Source:Google Reader

GizmoAnnotate 1.5.4 Build 180 (Freeware)

GizmoAnnotate 1.5.4 Build 180 (Freeware): Add customized annotations to your pictures (read more)

Source:Google Reader

Irregular Past Tense Verbs 1.0.0017 (Freeware)

Irregular Past Tense Verbs 1.0.0017 (Freeware): English grammar quiz for you to solve (read more)


Source:Google Reader

Day Of The Tentacle 1.0 (Freeware)

Day Of The Tentacle 1.0 (Freeware): An original truetype font (read more)


Source:Google Reader

2 Mark CS1252-OS

2 Mark CS1252-OS: ADHIPARASAKTHI COLLEGE OF ENGINEERING, G.B.Nagar, Kalavai.

141404 - OPERATING SYSTEM UNIT-I 1. What is an operating system? An operating system is a program that manages the computer hardware. It acts as an intermediate between a users of a computer and the computer hardware. It controls and coordinates the use of the hardware among the various application programs for the various users. 2. What is the kernel? A more common definition is that the OS is the one program running at all times on the computer ,usually called the kernel, with all else being application programs. 3. What are batch s

Source:Google Reader

Ten... freeware gems for new Macs

Ten... freeware gems for new Macs:

Complimentary benefits

Product Round -up  It seems that Mac OS is forever moving further towards a closed computing model, especially with the introduction of Gatekeeper in Mountain Lion. Don’t despair just yet though, Mac user can still take advantage of an abundance of free and open-source applications available in the traditional way.…

Source:Google Reader

RIM Announces 4G LTE PlayBook Tablet

RIM Announces 4G LTE PlayBook Tablet: RIM Announces 4G LTE PlayBook TabletRIM is launching a 4G LTE version of its 7-inch BlackBerry PlayBook tablet.



Source:Google Reader

Windows 8 security: Protection at the deepest level

Windows 8 security: Protection at the deepest level: Windows 8 security: Protection at the deepest level
MS is serious about security in Windows 8, implementing vastly improved protection of low-level activities such as memory allocation.
Read more: http://www.itproportal.com/2012/08/04/windows-8-security-protection-at-the-deepest-level/



Source:Google Reader

Toshiba Satellite U845-S402: Full Review

Toshiba Satellite U845-S402: Full Review: Toshiba's value-priced Ultrabook is easy to carry and lasts a long time on a charge, but competing laptops offer more performance and typing comfort for your money.
Source:Google Reader