#### Archived

This topic is now archived and is closed to further replies.

# The question nobody can answer (3D math)

## Recommended Posts

I have a 3D world. In this 3D world I have a camera that I want to move around. A rotation can only occur around an identity matrix. OK, so there is no problem to rotate the camera exactly how I want (around the x, y, and z axis). But! How do I move the camera forward/backward (ALWAYS to/from the direction of the look-at point no matter the rotation of the camera)? And don''t give me a picture of yet another matrix with some ones and zeros, because I need the actual math. I''m sure it''s really simple - just some sin and cos stuff on the camera''s x, y, and z values. But I can''t figure it out anyway. Please share the formula if you have it. The SDK says that the general formula to move and rotate the camera looks like this:
V = T * Rx * Ry *Rz;
V is the new matrix created. T is the translation matrix (and I don''t know how to calculate it, and I can''t find any info about it). Rx, Ry, Rz are the rotation matrices.

##### Share on other sites
I *think* this is the answer you're looking for...

Create one matrix for the body orientation using the D3DXMatrixRotation... functions. Call this BodyRot.

Create another matrix for the eye orientation using the D3DX functions. Call this EyeRot.

Create another matrix with D3DXMatrixTranslation and use the parameters (0.0f, 0.0f, WalkingDistance). Call it WalkDistance.

Now, concatenate the matrices as follows (order is very important):

FinalMatrix = EyeRot * WalkDistance * BodyRot.

It makes sense if you read it backwards:

Rotate the body to a new direction. Walk X units along the new Z direction (changed by the rotation). Then, turn your head by a certain rotation. If you draw it out on paper (with transformed axes) it makes sense.

This is the disadvantage of using LookAt. LookAt is easier, and you can retrieve these components from the matrix, but this is a much better approach, especially if you ever get into the "face one way, but fire the gun in the walking direction" kind of thing.

Is that what you were looking for?

Edited by - CrazedGenius on January 15, 2002 3:00:51 PM

##### Share on other sites
Rather then rotate your camera around the world basis, maintain a local basis around your camera. Then when the camera rotates you adjust the camera''s local basis accordingly. This also solves the gimbal lock problem. Gary Simmons had an article on this topic so your best bet is to head over to www.Mr-Gamemaker.com and post a message asking for the old tutorials. Also search for "Vector Camera".

ECKILLER

##### Share on other sites
quote:
Rather then rotate your camera around the world basis, maintain a local basis around your camera.

Isn''t that what I''m doing?

CrazedGenius,

I think the same problem remains.

Rotation: First you need to rotate the camera. One matrix is used for each axis (x, y, z). z is not used though unless you want to roll the camera. I only use x and y rotations.

Translation: Next you need to calculate the translation matrix depending on the angles of the camera . If I just add to the z element, as people are telling me to do everywhere, the camera will only move in the z direction. And I need to be able to walk in all directions (I want to walk in the direction I am looking). As it is now I just move on the z axis no matter the rotation of the camera.

Next you need to do:

FinalMatrix = Translation * RotX * RotY * RotZ;

That''s basically what the SDK says. Except that I don''t have a valid translation matrix! I don''t understand how to make one. That''s the problem.

quote:
Create one matrix for the body orientation using the D3DXMatrixRotation... functions. Call this BodyRot.

Create another matrix for the eye orientation using the D3DX functions. Call this EyeRot.

FinalMatrix = EyeRot * WalkDistance * BodyRot.

Maybe you method will work (I don''t know because I don''t really understand what''s happening in those matrices)... In that case, how do I set up BodyRot and EyeRot? I guess I could just rotate BodyRot with D3DXMatrixRotationYawPitchRoll, what about EyeRot? What should the difference between those two matrices be?

##### Share on other sites
OK admittidely i''m a 3D novice however couldn''t you do something like involving some kind of simultaneous moves vector.

something like, i''m currently rotating and also translating. then before each draw you do all the relative "simultaneous" transforms on the vectors.

so in your example, for instance you are translating and rotating at the "same time". so you first do a transform for rotation and then transform the resultant for a translate.

i suppose that works out to be the same as the EyeRot * WalkDistance * BodyRot thing but is a way to actually implement the idea?

-me

##### Share on other sites
This could be totally completely wrong, but I''ve always thought that an easy way to solve this problem is to do camera.position += camera.lookat, where position is a vector representing the camera''s position, and lookat being a vector representing where the camera is looking.

##### Share on other sites
quote:
Original post by FeelEvil
Translation: Next you need to calculate the translation matrix depending on the angles of the camera . If I just add to the z element, as people are telling me to do everywhere, the camera will only move in the z direction.

I think this is the point of confusion...

Get out a sheet of paper. Draw an X and Z axis (Y points out of the page). Draw a vector travelling straight down the Z axis. So far, so good.

Now, apply a rotation around the Y axis, say 45 degrees. Redraw the X and Z axes at this new 45 degree orientation. Redraw the vector straight down the Z axis. This vector should be 45 degrees from the old one, yet the translation (straight down Z) is the same in both cases. This is the direction of the body motion and of the eye vector.

Now, apply some final rotation, but no translation. This will affect the eye vector without "moving the body"

To put it another way, start over and draw the X and Z axis on the paper. Rotate 90 degrees. Now, after that rotation, a +Z translation will actually translate the object in either the -X or +X "universal" direction (depending on which direction you rotated.

As far as code, it's the same as I said before. A quick proof of this involves writing your paper experiment as code. Try different matrix multiplication orders, BUT USE THE EXACT SAME MATRICES (caps for emphasis, not yelling)

"Translate and then rotate" (R * T) = move to a new position and spin.

"Rotate and then translate" (T * R) = an orbitting effect because the object is rotated to a new angle and then moved along that angle.

Two different effects with the same matrices.

Edited by - CrazedGenius on January 15, 2002 5:33:19 PM

##### Share on other sites
This is taken directly from some of my old working DOS code. So, it's NOT neat but it will show you the math. Here ya go:

tempX = pntX;
pntX = (pntZ * sinDir) +
(pntX * cosDir);
pntZ = (pntZ * cosDir) -
(tempX * sinDir);

ltrans[_a].z = (pntY * sinPitch) +
(pntZ * cosPitch);
pntY = (pntY * cosPitch) -
(pntZ * sinPitch);

if (roll) {
ltrans[_a].x = (pntX * cosRoll) -
(pntY * sinRoll);
ltrans[_a].y = (pntX * sinRoll) +
(pntY * cosRoll);
}
else {
ltrans[_a].x = pntX;
ltrans[_a].y = pntY;
}

Man, that is hideous... but I'll try to explain. This is really just doing a 3D transformation based on Direction, Pitch and Roll... yes, I KNOW it's unorthadox... this was from my 1st attempt at a 3D engine years ago. ltrans is an array of points containing x, y and z coordinates and PntX, PntY and PntZ contain the temporary coordinates to be translated. The values, such as sinDir and cosDir, are double precision values containing the cosine and sin values for Dir, Pitch and Roll.

Now I know this isn't *exactly* what you are looking for but you can use this math to find the point that is ahead of the camera and move the camera to that point. In this case you could exclude the calculations for "roll" You should be able to transform the point (0, 0, x) where x is the distance you want the camera to move, and add that to your camera coordinates.

- Jay

Many of the truths we cling to depend greatly on our own point of view

Get Tranced!

Edited by - coderx75 on January 15, 2002 5:35:50 PM

##### Share on other sites
Hey, I''ve got an answer for you. I just solved this problem a few weeks ago using the knowledge from my grade 12 math class.

void CAMERA::MoveX(float distancex)
{
//if you''re looking at this trying to figure it out, you''re screwed
//do the movement for the x position
float A,B;//angles
float zmovement;
float xmovement;

A = ((int)(totalrotationy)/90)*90 - ((((int)(totalrotationy)/90)*90) - totalrotationy) - 270;
B = totalrotationy+180;

zmovement = sin(A * D3DX_PI / 180);
zmovement *= (distancex / sin(90));
xmovement = sin(B * D3DX_PI / 180) * (distancex / sin(90));

xpos+=xmovement;
zpos+=zmovement;

xtar+=xmovement;
ztar+=zmovement;
}

void CAMERA::MoveZ(float distance)
{
float xdistance;//the distance along the x axis from the target to the position
xdistance = xtar - xpos;
float zdistance;//the distance along the z axis from the target to the position
zdistance = ztar - zpos;

float zaxisdis = sqrt( xdistance * xdistance + zdistance * zdistance );
float distozratio = zdistance / zaxisdis ;
float distoxratio = xdistance / zaxisdis ;

if(zdistance == 0)
distozratio=0;

if(xdistance == 0)
distoxratio =0;

zpos += distozratio * distance;
ztar += distozratio * distance;
xpos += distoxratio * distance;
xtar += distoxratio * distance;

}

I don''t really feel like explaining this code. I actually commented in that this is unexplainable

rest assured this code works (for me) quite perfectly

##### Share on other sites
Oh yeah, I don''t have rotationx or rotation y matrices, I used a target and a camera position, and did all of my calculations around these. Then I used the D3DXMatrixLookAtLH after updating the position and rotation and everything

##### Share on other sites
quote:

"Translate and then rotate" (R * T) = move to a new position and spin.

"Rotate and then translate" (T * R) = an orbitting effect because the object is rotated to a new angle and then moved along that angle.

You have those backwards. When you translate and then rotate, you achieve the effect of moving the object away from the origin, then rotating the object around the world''s origin, not that object''s origin. This is the orbiting effect. FinalMatrix = Scale * Trans * ZRot * YRot * XRot or FinalMatrix = Scale * Trans * XRot * YRot * ZRot (can''t remember off hand on the rotation order).

When you rotate and then translate, you are rotating an object around its origin and then moving the object to the exact position (determing by the translation coordinates) in the world. This is the method used to position meshes in the world. FinalMatrix = Scale * XRot * YRot * ZRot * Trans

Off the top of my head, I think the following will work for you:

// Calculate the rotation matrix of cameraD3DXMATRIX matRotation;D3DXMatrixRotationYawPitchRoll(&matRotation, CameraYRotation, CameraXRotation, CameraZRotation);// Set Speed to speed of camera movement forwardD3DXVECTOR3 vecDir(0.0f, 0.0f, Speed);// Calculate new camera coordinatesD3DXVECTOR3 vecCam;D3DXVec3TransformCoord(&vecCam, &vecDir, &matRotation);CameraXPos += vecCam.x;CameraYPos += vecCam.y;CameraZPos += vecCam.z;

##### Share on other sites
quote:
You have those backwards.

With all respect, either we are arguing semantics, or you are incorrect.
EDIT: Read both of our posts again, our equations are the same.
"Translate and then Rotate" = R * T, you have S * R * R * R * T - basically the same thing, but arguing about it could prove confusing to the original poster.

Also, on the subject of confusing, I think many of the vector methods mentioned here might be over complicating the issues.

You can deal with everything as matrices. In the case of moving the camera, there's no reason to compute the direction vector if you are just going to use it as a transform. If you need the direction vector, it can be extracted from the view matrix without additional transformations (see the docs for D3DXMatrixLookAt). Some of the vector methods may be easier to see, but they are more work than is necessary.

Edited by - CrazedGenius on January 15, 2002 12:09:40 AM

##### Share on other sites
quote:
Original post by FeelEvil

The SDK says that the general formula to move and rotate the camera looks like this:

V = T * Rx * Ry *Rz;

That SDK would be hopelessly flawed for 3D... (gimbal lock)

Here's a cut&paste from my avatar class - when you call MoveForward, it moves the avatar in the direction it's facing. It's not exactly efficent, but it gets the job done.
  D3DXVECTOR3 m_v3Position; float m_fMovementRate_mps; float m_fStrafeRate_mps; BOOL m_bMoved; D3DXQUATERNION m_qFacing; float m_fTurnRate_rps; BOOL m_bTurned; D3DXMATRIX m_matOrientation; void CAvatar::MoveAhead(float fElapsed_sec) { float MoveRate = m_fMovementRate_mps * fElapsed_sec; D3DXVECTOR3 v3Looking_At, v3Up, v3Left; D3DI3D_QuaternionToOrthoV3(v3Left, v3Up, v3Looking_At, m_qFacing); m_v3Position += MoveRate * v3Looking_At; m_bMoved=TRUE; } void CAvatar::RotateRight(float fElapsed_sec) { D3DXQUATERNION dr; float TurnRate = m_fTurnRate_rps * fElapsed_sec; D3DMath_QuaternionFromAngles(dr.x, dr.y, dr.z, dr.w, 0.0f, -TurnRate, 0.0f); m_qFacing = dr * m_qFacing; m_bTurned = TRUE; } Depending on how you align the world matrix, you may need to twidle with the order or sign of x/y/z - it's all realtive, and I like to have my z axis go up&down not in&out like most 3D graphics.D3DXMatrixRotationQuaternion will take the quaterion and turn it into a rotation matrix, to use with the postion offset. Set the camera to that orientation, and voila.Matrici multiplicate piles-up backwards, you want to multiply the translation by the rotation matrix - the effect of which is to rotating the object _then translate it.Orientation_Matrix = Translation_Matrix * Rotation_Matrix void QuaternionToOrthoV3(D3DXVECTOR3 &v3Left, D3DXVECTOR3 &v3Up, D3DXVECTOR3 &v3Dir, const D3DXQUATERNION& qRot) { __int64 Start = RDTSC(); // Credit goes to Succinct of GameDev D3DXMATRIX matRot; D3DXMatrixRotationQuaternion(&matRot, &qRot); v3Left = D3DXVECTOR3(matRot(0,0), matRot(1,0), matRot(2,0)); v3Up = D3DXVECTOR3(matRot(0,1), matRot(1,1), matRot(2,1)); v3Dir = D3DXVECTOR3(matRot(0,2), matRot(1,2), matRot(2,2)); float x(qRot.x); float y(qRot.y); float z(qRot.z); float w(qRot.w); //* v3Left.x = 1 - 2 * (y*y + z*z); v3Left.y = 2 * (x*y + w*z); v3Left.z = -2 * (x*z - w*y); v3Up.x = 2 * (x*y - w*z); v3Up.y = 1 - 2 * (x*x + z*z); v3Up.z = 2 * (y*z + w*x); v3Dir.x = -2 * (x*z + w*y); v3Dir.y = 2 * (y*z - w*x); v3Dir.z = 1 - 2 * (x*x + y*y); __int64 End = RDTSC(); __int64 Ticks = End - Start; }

I always forget about that function...

Edited by - Magmai Kai Holmlor on January 15, 2002 12:24:15 AM

##### Share on other sites
To be honest I have gotten nowhere at all.

I tried the code Jim Addams provided and it doesn't seem to work. Or maybe I did something wrong.

I would prefer to do this with only matrices, but I guess it's just to forget that.

This is what I have, and I can't get past this point:

  // Calculate the translation matrix of cameraD3DXMatrixTranslation ( &matMov, 0, 0, speed ); // Apply translation to camera (move along the z axis) matFinal *= matMov; // Calculate the rotation matrix of cameraD3DXMatrixRotationYawPitchRoll( &matRot, D3DXToRadian(x), D3DXToRadian(y), 0 ); // Apply rotation matFinal *= matRot; g_pD3DDev->SetTransform ( D3DTS_VIEW, &matFinal );

And now when I walk, the camera can only move at along the z axis.
But everything looks alright.

So the only way I can think of that would solve this problem is to change the line

  D3DXMatrixTranslation ( matMov, 0, 0, speed );

to something else. Of course, I do have the angles the camera is rotated...
So in some way I need to calculate the translation matrix depending on those angles.

Will that work?

Anyway, now I'll check out all the other things people have posted.

Edited by - FeelEvil on January 16, 2002 9:10:57 AM

##### Share on other sites
Multiplication order matters. That''s the problem with using *= with matrices. Expand it to F = R * T

then, switch it to F = T * R. This should get you further.

##### Share on other sites
Sorry - I''ve been out a couple days.

quote:

"Translate and then Rotate" = R * T, you have S * R * R * R * T - basically the same thing, but arguing about it could prove confusing to the original poster.

No argument here - just pointing out that your equations were correct, just the text was backwards. Translate and then rotate = T * R, not R * T. You''ll see I corrected the order of the equations to match.

Now, to avoid further confusion - the original poster was not asking for a viewing transformation, which is what most of the posts are discussing. The original question is asking for a directional vector in which to move the camera based on a rotational matrix (or at least that''s what I take of it):
quote:

But! How do I move the camera forward/backward (ALWAYS to/from the direction of the look-at point no matter the rotation of the camera)? And don''t give me a picture of yet another matrix with some ones and zeros, because I need the actual math.

To FeelEvil -
The problem you are facing is that you are trying to use a 4x4 translation matrix as a vector matrix - won''t work. I still haven''t had a chance to check those calculations I gave you, but I believe it should work.
Basically, you are setting up a direction vector that moves the camera forward if there are no rotations. By appying a rotational matrix to the vector, you are changing the direction based on the rotational values.

##### Share on other sites
Sorry - hate to argumentative, but I think you are confusing the issue (in my mind at least)

"Translate and then rotate" is the same (to me) as saying "Walk across the room and spin". This is expressed with the equation "R * T" for mathematical reasons - it has nothing to do with the order of the words in the sentence. I''m being picky about this because the matrix multiplication order thing comes up so often. Maybe I''m off base here, but if people agree with my "walk across the room" example they will be misled by your explanations.

Perhaps it''s just semantics. The bottom line is that matrix multiplication is expressed from right to left. "Translate, rotate, and then scale" becomes "S * R * T".

I disagree more strongly with some of your other comments. It sounds like he has a (rotation) matrix to start with, and we know he needs a matrix at the very end of everything so that he can call SetTransform. You seem to be advocating taking the matrix, transforming a vector, and then presumably using that to rebuild a matrix. These seems slower, more complicated, and more convoluted than an all matrix approach.

FeelEvil - your original question seems to be "For any rotation matrix, how do I move along the look at vector". Add/replace the following code to the FrameMove function in the Pick Sample:

D3DXMATRIX matView;
D3DXMATRIX Trans;

D3DXMatrixTranslation(&Trans, 0.0f, 0.0f, 5.0f - fabs(sinf(m_fTime/3.0f)) * 4.0f);

D3DXMatrixLookAtLH( &matView, &vFromPt, &vLookatPt, &vUpVec );

matView = matView * Trans;

m_pd3dDevice->SetTransform( D3DTS_VIEW, &matView );

The LookAt function creates a matrix that orbits the camera around the tiger, always facing inward. Imagine the camera is on a circular rail, facing the center. The added lines create a translation matrix that always moves back and forth in the Z ("look at" in this case) direction. Notice that I never change the vector - it''s always on the Z axis.

The LookAt function essentially changes the Z axis and the translation matrix moves back and forth along that *new* Z axis.

Please tell me if this is not what you were looking for, but this is easier/faster/less error prone than extracting vectors and rebuilding matrices, IMHO.

##### Share on other sites

Normalise your lookat vector (so that it is a unit vector).

Then multiply that by the speed you wish to move.

##### Share on other sites
JonnyBoy has the same answer - my example built a directional vector you use to position the camera. Remember - the original question was not to build a matrix, but to move the camera in the position it was pointed.

##### Share on other sites
quote:
...but to move the camera in the position it was pointed.

and the best way to do that is build a matrix!

I'll stop now, normally I don't like to harp on people, but I'm really surprised this is even a point of contention. His original question did have to do with matrices:

quote:
The SDK says that the general formula to move and rotate the camera looks like this:
...
T is the translation matrix (and I don't know how to calculate it, and I can't find any info about it).

and we all know that the end result *must* be a matrix (for SetTransform), yet you are doing everything you can to introduce more steps (my translation is the one line equivalent to 6 lines of your original answer). That's the part I find so strange.

But like I said, I'll stop...

FeelEvil (If you're even still reading this ) - Jim's answer is perhaps more illustrative of what's going on within the math. Once you get a feel for things, my method can be used with less fuss.

Edited by - CrazedGenius on January 19, 2002 12:05:28 PM

##### Share on other sites
No, you are over complicating a very simple issue. The guy is working with a camera pos, and a lookat vec. He wants to move the camera along the lookat vector. The complete solution is...

assume D3DVECTOR pos is the camera position
assume D3DVECTOR lookat is the lookat vector

#include "d3dx8math.h" //for the D3DXVec2Normalize function

#define WALKSPEED 10.0f //the distance to move the camera
D3DVECTOR v; //temporary vector
D3DXVec2Normalize( &v, &lookat ); //normalise lookat
v=v*WALKSPEED; //turns your speed in to a vector pointing along the lookat
pos+=v;

There, that''s it. All done. Nothing more. No matrices, or any other nastiness.

ps. Can''t garantee I haven''t put any syntax errors in this, it hasn''t been lifted from existing working code.

##### Share on other sites
last time, I promise... (I'm just REALLY surprised this has turned into an argument! I found the tone of your reply very surprising. So, I feel I must respond...)

The original question explicitly asks about matrices AND any transformation is ultimately a matrix. What am I missing here?

D3DXMATRIX matRotation;
D3DXMatrixRotationYawPitchRoll(&matRotation, CameraYRotation, CameraXRotation, CameraZRotation);
D3DXVECTOR3 vecDir(0.0f, 0.0f, Speed);
D3DXVECTOR3 vecCam;
D3DXVec3TransformCoord(&vecCam, &vecDir, &matRotation);
CameraXPos += vecCam.x;
CameraYPos += vecCam.y;
CameraZPos += vecCam.z;
//(Added because they are necessary if you actually want to draw anything)
D3DXMATRIX matTrans;
D3DXMatrixTranslate(&matTrans, CameraXPos, CameraYPos, CameraZPos);
pDevice->SetTransform(D3DTS_WORLD, &(matRotation * matTrans));

my way:

D3DXMATRIX matRotation;
D3DXMatrixRotationYawPitchRoll(&matRotation, CameraYRotation, CameraXRotation, CameraZRotation);
D3DXMATRIX matTrans;
D3DXMatrixTranslate(&matTrans, 0.0f, 0.0f, Distance);
pDevice->SetTransform(D3DTS_WORLD, &(matRotation * matTrans));

I'm overcomplicating this how exactly?

Please keep in mind - my way transforms the lookat/travel vector implicitly AND at the same time concatenates the final matrix before calling SetTransform. In your method, the call to D3DXVec3TransformCoord is added and unnecessary processing (given that you have to concatenate the matrix anyway). I would call that an overcomplication and added processing (= slower). If you feel I am on the wrong track, please explain with civility.

Please don't take this the wrong way - someone in another thread mentioned that I don't get into flame wars. I'm only pursuing this because I'm so bemused that this is an argument. You can avoid matrices for awhile, but eventually you end up inventing little twists and turns that make things harder than they have to be. In my mind at least, my way has less steps and therefore less to debug, less to mistype, and less to keep track of. Given that you have to end up with a matrix anyway, I'm really surprised you're fighting this.

Edited by - crazedgenius on January 19, 2002 11:00:31 PM

##### Share on other sites
There''s no argument - you mentioned an argument in the first reply, that''s why I mentioned it. The original poster is the one that made mention of the matrices - not me. I think you''re taking this a little more serious than you should be

Let''s take an example to follow along:

You can safely discard the current position of the camera and deal with the rotation matrix that you already have. So, let''s say that the camera is pointed straight down (+1.57 radians along the X-Axis). Setup the rotation matrix:

D3DXMatrixRotationYawPitchRoll(&matRot, 0.0f, 1.57f, 0.0f);

Which comes out to the following matrix:

1.0 0.0 0.0 0.0
0.0 0.000796 1.0 0.0
0.0 -1.0 0.000796 0.0
0.0 0.0 0.0 1.0

Now, using your method, setup the translation matrix (to move forward +20.0f units):
D3DXMatrixTranslation(&matTrans, 0.0f, 0.0f, 20.0f);

No need to list the matrix, it''s empty except for row 4, which looks like this:

0.0 0.0 20.0 1.0

Multiply the two together (as you showed) you''ll get the following matrix:
1.0 0.0 0.0 0.0
0.0 0.000796 1.0 0.0
0.0 -1.0 0.000796 0.0
0.0 0.0 20.0 1.0

See the 4th row, 3rd column? That''s +20.0f in the z-axis, which is wrong. We''re looking for a direction downward along the negative y-axis.

Now, let''s look at my method. Setup the direction vector:

vecDir.x = vecDir.y = 0.0f;
vecDir.z = 20.0f;

Multiply the rotation matrix and vector to get the following translation values:
0.0 -19.99992 0.015925

That is the correct translation values to use for a camera pointing downward. If you don''t trust me, please by all means double check yourself.

Now, about the overcomplication, this method actually has way less multiplications in the process, with only a few more additions. That''s faster than the 4x4 multiplication you recommend.

To get back to FeelEvil, those calculations I listed worked, so I don''t know what might be wrong. Are you using the vectors as I showed in the first posting?

##### Share on other sites
To let everybody know regarding this thread - it will be closed. It seems to be shifting directions and before anything gets worse, I need to shut it down. Both parties have presented their views - let those that read it come to their own conclusions. If any further questions regarding the original topic is required, please start a new thread.

If you do not agree with this, please feel free to contract Dave or one of the other guys at GameDev.net and inform them of your thoughts.

Thanks!

##### Share on other sites
This topic is now closed to further replies.

• ### Forum Statistics

• Total Topics
628354
• Total Posts
2982236

• 10
• 9
• 11
• 24
• 11