I want to attach a camera on a vehicle like so that it will be in the cockpit of the car. I tried messing around with the target position of the view camera. I know there is a current position and target in a view  matrix. So I multiplied x and z components of target(view matrix) by 100 to give farther viewing capabilities. This did not work so I was wondering how to attach a a view camera to a vehicle. I just need a general idea on how to do it. 

|                  /

|              /

|          /

CurrentPosition --*100--->target position

View Matrix

thank you

 

No offense, but most of your opening post is very confusing (at least to me). E.g. there is no such thing like a target position within a view matrix. Moreover, "farther viewing" should be done by zooming. And multiplying a position is not meaningful from a mathematical point of view. So it seems me that a deeper insight may be helpful ...

Let's mostly ignore that the camera is somewhat special due to its view defining purpose. Instead, let's think of the camera as an object in the world like any other one. The placement (position and orientation) of the object w.r.t. the world is given as matrix C. Then the relation of a point (or direction) called v in the local space of the camera and its counterpart v' in world space is just

    v' = C * v

Bringing C onto the other side of the equation like so (where inv(...) means the inverse matrix)

    inv(C) * v' = inv(C) * C * v = v

defines the other way: Expressing a world co-ordinate v' in the local space of C.

Especially w.r.t. the camera, C may be called "camera matrix", and inv(C) may be substituted by V what usually is called the "view matrix" in the context of cameras, because the view matrix is just the inverse of the camera matrix. (The math itself is universal to spaces regardless that we apply it to the camera in this case.)

Attaching the camera to the vehicle means to make a geometrical constraint, so that moving the vehicle "automatically" moves the camera, too. This kind of thing is usually called "parenting" or - more technically - "forward kinematic". This means that we define a "local placement" L for the camera, i.e. a spatial relation that expresses the position and orientation of the camera not in the world but w.r.t. the vehicles world placement W. In other words, L defines how much translation and rotation must be applied to a vector in camera's local space so that it is given in the vehicle's local space.

The formula needed to transform from a local space to its parent space is already shown above, where we've used the world space as the parent space. However, an indefinite number of parent spaces can be used. What we want here is to go from the camera local space into the vehicle local space, and from there to the world space. So we have

    v' = L * v
    v'' = W * v'

or together

    v'' = W * ( L * v ) = ( W * L ) * v

from what we see that the "parenting" just means to concatenate the particular transformation matrices. But be aware that matrix multiplication is not commutative, so the order of the matrices is important. In the given example we have a composited matrix

    W * L

for parenting.

Now the question pop up of how L is build. As a placement it has both a positional and an orientational part. Both can be set to fixed values, meaning that the camera is installed with a static device into the vehicle cockpit. Less strict parenting can be done, too. E.g. the position can be fixed while the orientation can be driven by targeting a "look-at" point. Let's investigate this example a bit further.

So we define that the placement matrix L is composed from a translational and a rotational part, T and R resp., in the usual order (as you've hopefully noticed, this post uses column vectors):

    L := T * R

To calculate the look-at vector, i.e. the unit direction vector from the position of the camera to the target point, the both positions must be given in the same space, and the resulting look-at vector will be in that space, too. Because L is given in vehicle space, and R (which the look-at vector is a part of) is hence also, we are interested in a vehicle local look-at vector. T is already vehicle local, but the target point p should be given in world space. So we need to transform it first

    inv(W) * p

and can then compute the difference vector

   d = inv(W) * p - T * 0 

where 0 denotes the origin point vector in homogeneous co-ordinates, i.e. [ 0 0 0 1 ]. From here normalization and matrix building is done as usual, so I neglect that stuff here.

HtH

Basically, "what Haegarr said"! But maybe a little more directly to the point: If you multiply a matrix times another matrix and use the result as the matrix for the child, you have a parent-child relationship where the parent is attached to the child, but the child is not attached to the parent. So, moving the parent moves the child, but the child can still move freely independent of the parent.

 

The camera/view matrix is basically the same thing as an object/world matrix it's just inverted. If you invert it again, you will have a matrix for the camera that you can treat exactly like any object's matrix. 

 

I sometimes have to play with the multiplication order and the inverses a bit because I don't memorize the math and it's pretty much just "do it the other way" if it doesn't work. But you could invert the view matrix and multiply it times the object's matrix and then invert the result back and use that for your view matrix, and I think that would make the camera's position relative to the object rather than to the origin of the world. Reverse the multiplication order if it doesn't work. (I'm sure there's a more direct/efficient way here, but that method would maybe make it most clear what's happening).

You can chain these as well. So, what I would do is have a "camera boom" matrix as a child of the car body. Then you can use the camera boom matrix to set a camera position, such as the driver's seat or modify it again and make it a chase camera and modify it again to put it in the passenger seat. Then make the camera/view matrix a child of the "camera boom" matrix and a grand-child of the car's matrix. 

 

Just keep in mind that the camera is inverted because it has to be backwards. If you understand the projection matrix, you understand that a view matrix is moving the entire world around the camera position rather than the camera moving through the world. The real camera is the projection matrix and it is stationary and unable to move. The illusion of movement is created by the view matrix moving the entire game universe past the camera.

 

So, if you tell the camera to move left, it moves the entire world right by that amount. If you tell the camera to move forward, the view matrix moves the entire world backwards by that amount. THAT is why it is inverted; it has to do everything backwards to function. Otherwise it's the same as any object's matrix. So, invert the view matrix and you can treat it like an object matrix, you just have to invert it back before using it as a view matrix.

 

And the parent child thing is done by multiplying one matrix by the other and using the result as the matrix for the child, thus never actually using its matrix for anything other than manipulating it and this calculation.

 

If it's helpful, I have a tutorial on almost exactly this on my website. 

There is some more stuff on that here.

And especially this "Toy Car" example here (working example, not really a tutorial) does almost exactly what you are wanting to do although it's more of a chase camera from what I remember. I built it years ago.

Problem is it is in XNA. But if you can get past the C# code, the math is exactly the same regardless.

The Toy Car example is actually like the 6th example in my opening montage on my YouTube channel. 

 

There's even a

" rel="external">video on matrices on my YouTube channel, although it doesn't cover rigid animation, which is what you're trying to do here. It's just that rigid animation is usually between two objects rather than an object and the camera. Just remember that if you invert the view matrix you can treat it like any other object, as long as you invert it back again before using it as a view matrix.