GameCamera: a third person, aiming camera (that works!)
by Michael Bacon · in Torque Game Engine · 09/13/2007 (6:44 am) · 81 replies
Update: I have fixed the jitter and the issues I had with the network code. I think everything is working as it should be.
Well, I've been working on a new third person camera. I wanted the player to aim where my third person camera is looking.
This has been sought after by quite a few people including myself. I didn't find what I was looking for elsewhere so here is my attempt.
I've got the basics working. This camera was built on a HUGELY modified Advanced Camera but has pretty much grown into its own being. It is now called the GameCamera.
Features:
Third person camera
Player fires where camera is looking
The server controls where the camera should be
Caveats:
No server side interpolation is done (for instance if you switch targets the client side will interpolate the difference in like one tick but the server will have already been there. I hope to add this later.
Download here and add gameCamera.cc and gameCamera.h to your project in under the engine\game folder.
Video here shows the camera in action while fighting a bot.
------------------------------------------------
If you follow all the directions here (especially the one about setting the 'correctMuzzleVector = true' value on your weapon datablock) you will have a third person camera and a player that fires at the center of your screen.
------------------------------------------------
In order to implement the camera you need to make a few changes...
Well, I've been working on a new third person camera. I wanted the player to aim where my third person camera is looking.
This has been sought after by quite a few people including myself. I didn't find what I was looking for elsewhere so here is my attempt.
I've got the basics working. This camera was built on a HUGELY modified Advanced Camera but has pretty much grown into its own being. It is now called the GameCamera.
Features:
Third person camera
Player fires where camera is looking
The server controls where the camera should be
Caveats:
No server side interpolation is done (for instance if you switch targets the client side will interpolate the difference in like one tick but the server will have already been there. I hope to add this later.
Download here and add gameCamera.cc and gameCamera.h to your project in under the engine\game folder.
Video here shows the camera in action while fighting a bot.
------------------------------------------------
If you follow all the directions here (especially the one about setting the 'correctMuzzleVector = true' value on your weapon datablock) you will have a third person camera and a player that fires at the center of your screen.
------------------------------------------------
In order to implement the camera you need to make a few changes...
#42
As far as I can tell, it seems somehow you are processing ticks twice while in 1st person. Not sure how to get around it yet.
10/20/2007 (11:29 pm)
Thanks for the update Brian. However, the problem in first person is still present.As far as I can tell, it seems somehow you are processing ticks twice while in 1st person. Not sure how to get around it yet.
#43
I don't personally use first person mode so I haven't tested this.
Try this:
Edit:
I ran a test and this seemed to fix the issues.
10/20/2007 (11:43 pm)
Could the camera object be the same as the control object?I don't personally use first person mode so I haven't tested this.
Try this:
{
control->processTick(&movePtr[m]);
// give camera a chance to look at movement
if (camera != control)
if (camera && camera->mProcessTick)
camera->processTick(&movePtr[m]);
m++;
}Edit:
I ran a test and this seemed to fix the issues.
#45
Thank you Ron and Brian for the quick fix.
Brian, if you haven't done so.. Please submit this as a regular resource!
It is a the best 3rd camera i tried!
10/21/2007 (6:56 am)
Yup that works like a charm!Thank you Ron and Brian for the quick fix.
Brian, if you haven't done so.. Please submit this as a regular resource!
It is a the best 3rd camera i tried!
#46
/server/scripts/camera.cs : Unable to instantiate non-conobject class GameCameraData
10/21/2007 (5:14 pm)
Im trying to get your camera to work, but I don't think the actual camera is being created. The game loads okay, just as if I never made any changes. I have your header files included in the right place I believe and just don't know where I went wrong?/server/scripts/camera.cs : Unable to instantiate non-conobject class GameCameraData
#47
10/22/2007 (1:25 am)
Have you added gameCamera.cc/h to your project and recompile?
#48
And make sure you are running the correct copy that you have built.
10/22/2007 (3:58 am)
Make sure to do clean your project before recompiling. Sometimes the compiler won't notice new files...And make sure you are running the correct copy that you have built.
#49
It's easy to reproduce...
In Player-Datablock set:
cameraMaxDist = 10;
observeParameters = "0.5 6.5 6.5";
Now find terrain with a bit greater surfaceAngle (~20+), and collide to it with the camera. If you find a right place (and that is easy), you can reproduce this to 100%.
Since Torque-Camera, and Advanced Camera have the same issue, maybe its not the Camera? Maybe its some thing with the terrain? Were great if we can find it out, it seems to be a very old bug.
Update:
Have played a bit with Camera::validateEyePoint, but with no result.
Update2:
Ok, if you set DISTANCE_FROM_COLLISION to 2.0, it seems to *work*.. probably only a hack, i will test it now ;)
Update3:
It works, but in my game i have then a jittering problem, in the clean TGE 1.5.2+gameCamera i have no jittering.
10/23/2007 (12:58 am)
Brian, i have now added this ressource to a clean TGE 1.5.2, and here are still collision issues with the terrain...It's easy to reproduce...
In Player-Datablock set:
cameraMaxDist = 10;
observeParameters = "0.5 6.5 6.5";
Now find terrain with a bit greater surfaceAngle (~20+), and collide to it with the camera. If you find a right place (and that is easy), you can reproduce this to 100%.
Since Torque-Camera, and Advanced Camera have the same issue, maybe its not the Camera? Maybe its some thing with the terrain? Were great if we can find it out, it seems to be a very old bug.
Update:
Have played a bit with Camera::validateEyePoint, but with no result.
Update2:
Ok, if you set DISTANCE_FROM_COLLISION to 2.0, it seems to *work*.. probably only a hack, i will test it now ;)
Update3:
It works, but in my game i have then a jittering problem, in the clean TGE 1.5.2+gameCamera i have no jittering.
#50
None of this pertains to my camera. Are you sure you are actually using a GameCamera?
I noticed while reapplying this resource to another clean copy of TGE that I used some of the same script variable names as the advanced camera. Are you trying to use both cameras at once?
After playing with it for awhile I can say that I can not reproduce your problem with the GameCamera.
10/23/2007 (3:28 am)
Quote:
t's easy to reproduce...
In Player-Datablock set:
cameraMaxDist = 10;
observeParameters = "0.5 6.5 6.5";
...
Update:
Have played a bit with Camera::validateEyePoint, but with no result.
None of this pertains to my camera. Are you sure you are actually using a GameCamera?
I noticed while reapplying this resource to another clean copy of TGE that I used some of the same script variable names as the advanced camera. Are you trying to use both cameras at once?
After playing with it for awhile I can say that I can not reproduce your problem with the GameCamera.
#51
and yes, as you can see on the second screenshot its gameCamera and i used MyGameCameraData from this thread. I have removed standard torque camera from the project.
But this "bug" has something not only with the gameCamera, it must be something else, because all cameras (basic torque camera, advCamera, gameCamera) seems to have this bug.
Have tested it with basic torque camera (that was the "Camera::validateEyePoint"-Part), but with no result.
I try to find out, what it can be. The larger collision distance is only a hack, not a solution. Inside a small building or a forest it will make problems.
And this collision bug is related not only to the terrain, have tested it now with TSStatics and DIFs, the same problem.
10/23/2007 (5:05 am)
Only the first part (cameraMaxDist = 10; observeParameters = "0.5 6.5 6.5";) was related to gameCamera,and yes, as you can see on the second screenshot its gameCamera and i used MyGameCameraData from this thread. I have removed standard torque camera from the project.
But this "bug" has something not only with the gameCamera, it must be something else, because all cameras (basic torque camera, advCamera, gameCamera) seems to have this bug.
Have tested it with basic torque camera (that was the "Camera::validateEyePoint"-Part), but with no result.
I try to find out, what it can be. The larger collision distance is only a hack, not a solution. Inside a small building or a forest it will make problems.
And this collision bug is related not only to the terrain, have tested it now with TSStatics and DIFs, the same problem.
#52
Edit:
Ughh, so I really think that the problem is that the camera should have volume but we're only doing ray casts. The problem occurs when the camera is very close to the object but no collision actually occurs. I'm not sure about the best way to go about fixing this right now, I'm about to go to bed. But I'll be working on it for sure.
I'd like to use a bounding sphere test but I'm not sure how to do that just yet...
Edit again...
After looking at it for a while, I'll probably be adding proper Convex collision for the camera soon.
Thats gonna take a little bit of effort to get right but I've already got some ideas.
10/23/2007 (5:53 am)
Ah HA! I think I've tracked down an issue... I'll modify this post in a little bit when I have more info!Edit:
Ughh, so I really think that the problem is that the camera should have volume but we're only doing ray casts. The problem occurs when the camera is very close to the object but no collision actually occurs. I'm not sure about the best way to go about fixing this right now, I'm about to go to bed. But I'll be working on it for sure.
I'd like to use a bounding sphere test but I'm not sure how to do that just yet...
Edit again...
After looking at it for a while, I'll probably be adding proper Convex collision for the camera soon.
Thats gonna take a little bit of effort to get right but I've already got some ideas.
#53
10/23/2007 (6:22 am)
Oh, it will be great! :)
#54
10/23/2007 (9:02 pm)
Brian - I think I found an interesting problem with this code. Repeated changing of controling objects such as mounting and dismounting vehicles sometimes causes it freak out and start jittering or updating improperly.
#55
I don't think my initial idea will yield the results we want.
I'm not sure why repeated changes in control would cause the camera to go wonky but I'm no expert at how this all works... Any insights?
Changing the following line in Player.cc MIGHT help, I dunno.
In Player::processTick at the end of the function:
10/24/2007 (3:33 am)
Ugh, I don't take mounted stuff into account and I don't use vehicles.I don't think my initial idea will yield the results we want.
I'm not sure why repeated changes in control would cause the camera to go wonky but I'm no expert at how this all works... Any insights?
Changing the following line in Player.cc MIGHT help, I dunno.
In Player::processTick at the end of the function:
if (!isGhost())
{
// Animations are advanced based on frame rate on the
// client and must be ticked on the server.
updateActionThread();
updateAnimationTree([b]isFirstPerson()[/b]);
}
#56
If you use the standard game camera while using the modification this resource makes to the game process list it will cause the camera to always process the move information (rather than only processing it when you set the camera as the control object).
The easiest way to fix this would be to check in the standard camera if it is actually the control object.
I'd change Camera::processTick to use this if statement at the top. I'm not sure if this works 100% though but I thought I'd throw it out there.
10/24/2007 (6:44 am)
I just had a thought I'd like to share....If you use the standard game camera while using the modification this resource makes to the game process list it will cause the camera to always process the move information (rather than only processing it when you set the camera as the control object).
The easiest way to fix this would be to check in the standard camera if it is actually the control object.
I'd change Camera::processTick to use this if statement at the top. I'm not sure if this works 100% though but I thought I'd throw it out there.
if (move && getControllingClient() &&
(getControllingClient()->getControlObject() == this))
#57
The camera collision hasn't been reworked yet but its on my list of things to do. The camera is not a priority at this time so it might be a little bit before I can fix it but it'll come. For now it works quite well unless you get REALLY close to a collision plane but don't actually collide. In that case you might see through things.
Finally, I have just uploaded a new zip file. This update cleans things up ALOT (I am really starting to get comfortable within the engine). It also adds the ability for the Game Camera to be used as a fly cam. Setting any GameCamera object as the Control Object of a connection will cause it to fly around controlling itself just like the stock TGE camera. The flycam doesnt remember its position though so if you switch between them you'll have to set it yourself.
As a last thought, I am thinking about ways to add in different camera behaviors. I'd like to add an orbit mode as well. I'm just really not sure how to do this without adding a lot of overhead to the code. Abstracting the update functions seems the best place but I'm considering just making a new camera object that inherits from GameCamera instead. Its really a debate between forcing different camera modes to be controlled by a single object or requiring a new camera object from each camera mode.
10/26/2007 (3:36 am)
Okay, so I don't know anything about the issues Ron is having. If I can get a test case (Ron can you set me up with something simple or at least tell me exactly I need to do to test this?) I can try to figure it out.The camera collision hasn't been reworked yet but its on my list of things to do. The camera is not a priority at this time so it might be a little bit before I can fix it but it'll come. For now it works quite well unless you get REALLY close to a collision plane but don't actually collide. In that case you might see through things.
Finally, I have just uploaded a new zip file. This update cleans things up ALOT (I am really starting to get comfortable within the engine). It also adds the ability for the Game Camera to be used as a fly cam. Setting any GameCamera object as the Control Object of a connection will cause it to fly around controlling itself just like the stock TGE camera. The flycam doesnt remember its position though so if you switch between them you'll have to set it yourself.
As a last thought, I am thinking about ways to add in different camera behaviors. I'd like to add an orbit mode as well. I'm just really not sure how to do this without adding a lot of overhead to the code. Abstracting the update functions seems the best place but I'm considering just making a new camera object that inherits from GameCamera instead. Its really a debate between forcing different camera modes to be controlled by a single object or requiring a new camera object from each camera mode.
#58
10/26/2007 (4:35 am)
Brian disregard my problem, I got it figured out. It was my fault.
#59
How is everything else?
10/26/2007 (5:10 am)
Sweet! I love bugs that go away without my intervention :)How is everything else?
#60
updateCameraStats();
It causes an error. I am assuming it is not required?
10/26/2007 (5:54 am)
One small problem. You new version has this at line 310 in gamecamera.ccupdateCameraStats();
It causes an error. I am assuming it is not required?
Torque Owner Michael Bacon
Default Studio Name
The code you pasted above was an older and incorrect version of this code. I noticed WEIRD problems when I did this on accident.
The relevant blocks should look like this:
{ control->processTick(&movePtr[m]); // give camera a chance to look at movement if (camera && camera->mProcessTick) camera->processTick(&movePtr[m]); m++; }