Camera Problems
by Frank Davies · in Torque 3D Beginner · 09/18/2013 (6:56 am) · 29 replies
Hi all,
I've been experimenting with TorqueScript for a couple of days now, and while it's a nice platform the way the camera works seems very unintuitive. My long-term aim is to create a 2.5D game (2d gameplay, 3d environment) where the camera sits overhead and looks down on the player, while still tracking their position. This would create an isometric perspective similar to that found in Diablo, Torchlight, and so on.
However, I can't seem to do anything with the camera. I've been experimenting using Daniel Buckmaster's T3D Bones tutorial as the basis, but all I seem to be able to do, even after researching and messing around with script for several hours, is move the camera to a third-person view behind the player when the game starts.
Are there any simple ways to change the position and rotation of the player camera? I looked into the RTS and Adventure tutorials, but they have a much larger codebase than would be necessary or suitable for my purposes - I don't need most of their functionality. I'm willing to alter the Torque Engine itself if necessary, as I have sufficient experience with C++ programming to do so.
Any other information about camera control etc. would also be very helpful.
I've been experimenting with TorqueScript for a couple of days now, and while it's a nice platform the way the camera works seems very unintuitive. My long-term aim is to create a 2.5D game (2d gameplay, 3d environment) where the camera sits overhead and looks down on the player, while still tracking their position. This would create an isometric perspective similar to that found in Diablo, Torchlight, and so on.
However, I can't seem to do anything with the camera. I've been experimenting using Daniel Buckmaster's T3D Bones tutorial as the basis, but all I seem to be able to do, even after researching and messing around with script for several hours, is move the camera to a third-person view behind the player when the game starts.
Are there any simple ways to change the position and rotation of the player camera? I looked into the RTS and Adventure tutorials, but they have a much larger codebase than would be necessary or suitable for my purposes - I don't need most of their functionality. I'm willing to alter the Torque Engine itself if necessary, as I have sufficient experience with C++ programming to do so.
Any other information about camera control etc. would also be very helpful.
#2
Also, in the documentation is a tutorial that continues where the RTS Prototype leaves off to make an adventure style game with fixed camera locations and "rooms" like Resident Evil or Parasite Eve.
09/18/2013 (10:15 am)
Except skip the "create a new project" part - it's outdated.Also, in the documentation is a tutorial that continues where the RTS Prototype leaves off to make an adventure style game with fixed camera locations and "rooms" like Resident Evil or Parasite Eve.
#3
By the way mate, where can I post bugs for that? None of my NPCs have weapons in their inventory.
09/18/2013 (10:20 am)
I did include both parts of that series Richard. Albeit in reverse order. By the way mate, where can I post bugs for that? None of my NPCs have weapons in their inventory.
#4
From exploring the script it becomes clear that, for example, the server commands you add to scripts/server/commands.cs are nothing more than wrappers for the actual functions that are called:
What I'm looking for is the raw code that alters the camera position, without the fat of the server commands.
09/18/2013 (12:50 pm)
Like I said, I've read through both parts of that series and think they use a lot of extra script that I'm unlikely to ever need or want. That's why I'm building from T3D Bones rather than the tutorial templates.From exploring the script it becomes clear that, for example, the server commands you add to scripts/server/commands.cs are nothing more than wrappers for the actual functions that are called:
function serverCmdoverheadCam(%client)
{
%client.camera.position = VectorAdd(%client.player.position, "0 0 30");
%client.camera.lookAt(%client.player.position);
%client.camera.controlMode = "Overhead";
}What I'm looking for is the raw code that alters the camera position, without the fat of the server commands.
#5
If you're not planning on using the multiplayer functionality at all you could crunch out all of the client/server separation, but honestly if you're just looking to set the camera mode once and forget it then it's just not worth the effort.
09/18/2013 (7:09 pm)
"Nothing more than wrappers" - except that you can't control the camera from the client. It is used to scope ghosts on the server. "Fat" is not significant when changing camera modes unless you're doing it a hundred times a second.If you're not planning on using the multiplayer functionality at all you could crunch out all of the client/server separation, but honestly if you're just looking to set the camera mode once and forget it then it's just not worth the effort.
#6
(This is a part of Torque's legacy as an FPS-optimised engine, which is slowly changing.)
What I recommend you do instead is make the Camera your control object (as in the camera movement tutorial), and spawn an AIPlayer for your actual player. In the movement key functions, call setMoveDestination on the AIPlayer to have it move in cardinal directions (i.e. call setMoveDestination("0 1000000 0"); to have it move in the +y direction). Here's an example of a following camera I wrote for a game using the t3d-bones template - it tracks a group of objects on a specified axis. I initialise it here.
EDIT: The server commands are very necessary if you want to make a multiplayer game, because the client isn't permitted to directly modify game state parameters like object positions. Conversely, the server can't touch the client's GUI objects and so on. So they need to use client/server commands to communicate.
t3d-bones isn't a multiplayer template, so a lot of existing scripts and tutorials won't be applicable to it unfortunately.
09/18/2013 (8:37 pm)
The problem you'll run into is that if you have a Player as a control object (as in the t3d-bones player tutorial), Torque won't let you use an alternative camera - it will lock you in to first- or third-person view.(This is a part of Torque's legacy as an FPS-optimised engine, which is slowly changing.)
What I recommend you do instead is make the Camera your control object (as in the camera movement tutorial), and spawn an AIPlayer for your actual player. In the movement key functions, call setMoveDestination on the AIPlayer to have it move in cardinal directions (i.e. call setMoveDestination("0 1000000 0"); to have it move in the +y direction). Here's an example of a following camera I wrote for a game using the t3d-bones template - it tracks a group of objects on a specified axis. I initialise it here.
EDIT: The server commands are very necessary if you want to make a multiplayer game, because the client isn't permitted to directly modify game state parameters like object positions. Conversely, the server can't touch the client's GUI objects and so on. So they need to use client/server commands to communicate.
t3d-bones isn't a multiplayer template, so a lot of existing scripts and tutorials won't be applicable to it unfortunately.
#7
09/18/2013 (10:41 pm)
Quote:(This is a part of Torque's legacy as an FPS-optimised engine, which is slowly changing.)An almost exclusively multiplayer FPS. Tribes and Tribes 2 each had a sad little "single player campaign" that consisted of 8 or so training missions - to get you used to the controls before you got vaporized by real people. The game this engine derived from was not really meant for single player use at all....
#8
09/19/2013 (12:35 am)
Good point.
#9
The project I'm working on is single-player only, which is why I see the server-client model as an obstacle rather than a blessing. Unfortunately Torque is also the best engine for my purposes - dynamic lighting is key to my project, and short of buying Unity Pro (which I can't afford) Torque is my best choice for that.
09/19/2013 (1:36 am)
Thanks for the idea and script examples, Daniel. The project I'm working on is single-player only, which is why I see the server-client model as an obstacle rather than a blessing. Unfortunately Torque is also the best engine for my purposes - dynamic lighting is key to my project, and short of buying Unity Pro (which I can't afford) Torque is my best choice for that.
#10
09/19/2013 (6:00 am)
Out of interest, how did you find out about/decide on T3D?
#11
0) Write a bespoke engine. (Ridiculous time investment.)
1) Use an open-source 2D game engine and write bespoke code to produce lighting effects. (Large investment of time and effort.)
2) Find a 2D game engine with decent lighting systems already implemented. (As far as I can tell, none exist.)
3) Use a 3D engine and mess around with it to produce a 2.5D effect. (Best option.)
I looked through my options for getting a dynamic lighting system, informed in part by this article and looked through the websites of a number of different game engines.
Initially I tried Unity, but hadn't double-checked its Pro features carefully enough: you need the Pro version to use its dynamic lighting for point and spot lights. When I realised that (luckily quite early) I went back to looking for engines.
I'd heard Torque mentioned by other indie developers before, and it's an engine that's been proven on a number of games, unlike others that have similar features. While the server/client model wasn't something I was aware of initially, your t3d-bones template/tutorial made it obvious that I didn't need most of the functions for server communication unless I was making a multiplayer game.
tl;dr: It was the best choice for the features I need and the money I can afford to spend on development (maybe £500 at this early stage; I'd rather focus spending on art etc.). I'm hoping to hack out a demo in a few months and maybe attract an artist and/or funding with that.
09/19/2013 (6:42 am)
Well, I realised I needed a 3D game engine after considering the options for lighting a 2.5D environment, which came down to:0) Write a bespoke engine. (Ridiculous time investment.)
1) Use an open-source 2D game engine and write bespoke code to produce lighting effects. (Large investment of time and effort.)
2) Find a 2D game engine with decent lighting systems already implemented. (As far as I can tell, none exist.)
3) Use a 3D engine and mess around with it to produce a 2.5D effect. (Best option.)
I looked through my options for getting a dynamic lighting system, informed in part by this article and looked through the websites of a number of different game engines.
Initially I tried Unity, but hadn't double-checked its Pro features carefully enough: you need the Pro version to use its dynamic lighting for point and spot lights. When I realised that (luckily quite early) I went back to looking for engines.
I'd heard Torque mentioned by other indie developers before, and it's an engine that's been proven on a number of games, unlike others that have similar features. While the server/client model wasn't something I was aware of initially, your t3d-bones template/tutorial made it obvious that I didn't need most of the functions for server communication unless I was making a multiplayer game.
tl;dr: It was the best choice for the features I need and the money I can afford to spend on development (maybe £500 at this early stage; I'd rather focus spending on art etc.). I'm hoping to hack out a demo in a few months and maybe attract an artist and/or funding with that.
#12
09/19/2013 (8:10 am)
I never tl;dr ;). Thanks for that writeup. We're a small community, so it's always nice to know how we grow, what attracts people to Torque.
#13
Speaking of which - when using T3D for multiplayer games always test in single-player, multiplayer hosted from the client and multiplayer hosted on a dedicated server. There are differences....
Sounds like you're going for a Diablo 3-style camera/movement scheme. Should be pretty cool - keep us updated.
09/19/2013 (8:42 am)
Actually, the client/server rift isn't that horrible in single player - the engine detects most instances and short-circuits the loop. It's just a slight bit of pain on the scripting side, and there are a few shortcuts there too - just can't really think of many off the top of my head because my current project is meant to be strongly multiplayer.Speaking of which - when using T3D for multiplayer games always test in single-player, multiplayer hosted from the client and multiplayer hosted on a dedicated server. There are differences....
Sounds like you're going for a Diablo 3-style camera/movement scheme. Should be pretty cool - keep us updated.
#14
How exactly does the setTransform (rotation and position) function work? I've been experimenting with the camera system, and I've worked out the following from getTransform. As an example I'll use a sample from that function.
[0, 0, 0, 1, 0, 0, 1.507]
This causes the camera to point directly downwards. The first three numbers are position coordinates (along the x, z, y axis respectively: why not x, y, z like a sane function?) The last 4, which are rotation coordinates, make less sense. As far as I can tell, the first 3 numbers represent the proportion of rotation around the x, y, and z axis (maybe x, z, y - who knows?) and the last represents the number of pi to rotate through, meaning that in my example we've rotated around the x axis by pi/2 (1/2 radian) and around the other two not at all.
I.e. the last 4 numbers mean you rotate around x by 1/2 radian, around y by nothing, and around z by nothing.
I'm not great at maths though, so there could be something to do with rotation matrices going on that I just don't understand.
Again, any help would be much appreciated.
09/19/2013 (12:17 pm)
Thanks for the help, guys. Just one more thing to add.How exactly does the setTransform (rotation and position) function work? I've been experimenting with the camera system, and I've worked out the following from getTransform. As an example I'll use a sample from that function.
[0, 0, 0, 1, 0, 0, 1.507]
This causes the camera to point directly downwards. The first three numbers are position coordinates (along the x, z, y axis respectively: why not x, y, z like a sane function?) The last 4, which are rotation coordinates, make less sense. As far as I can tell, the first 3 numbers represent the proportion of rotation around the x, y, and z axis (maybe x, z, y - who knows?) and the last represents the number of pi to rotate through, meaning that in my example we've rotated around the x axis by pi/2 (1/2 radian) and around the other two not at all.
I.e. the last 4 numbers mean you rotate around x by 1/2 radian, around y by nothing, and around z by nothing.
I'm not great at maths though, so there could be something to do with rotation matrices going on that I just don't understand.
Again, any help would be much appreciated.
#15
It goes "x y z x y z theta"
Also, have you probably noticed, the Z axis in Torque is up and down, and the Y axis is depth.
If you just wanted to set the position without messing up the rotation, then you could simply use something like this:
%position = "0 0 100";
%rot = getWords(%obj.getTransform(), 3, 6);
%obj.setTransform(%position SPC %rot);
And lastly, remember that the theta only takes radians, but in the level editor, the rotation property in the object's inspector is actually in degrees.
09/19/2013 (12:41 pm)
as you are aware, vectors in TS are strings separated by a space for their components. The transform is a 3 dim. position vector and an angle-axis matrix, where its x y z theta.It goes "x y z x y z theta"
Also, have you probably noticed, the Z axis in Torque is up and down, and the Y axis is depth.
If you just wanted to set the position without messing up the rotation, then you could simply use something like this:
%position = "0 0 100";
%rot = getWords(%obj.getTransform(), 3, 6);
%obj.setTransform(%position SPC %rot);
And lastly, remember that the theta only takes radians, but in the level editor, the rotation property in the object's inspector is actually in degrees.
#16
In the Adventure Prototype I just directly set the position and rotation fields on the camera - too lazy to figure that all out.
However, just now I was digging and found source/math/mTransform.h which contains the TransformF class that handles all of that stuff....
09/19/2013 (1:21 pm)
I think it might be easier to use setPosition() and then setRotation() - setRotation() looks like it only wants a normalized vector (Point3F).In the Adventure Prototype I just directly set the position and rotation fields on the camera - too lazy to figure that all out.
However, just now I was digging and found source/math/mTransform.h which contains the TransformF class that handles all of that stuff....
#17
Also, I think only the Camera class has a setRotation function. Just be aware.
That 4-element rotation component doesn't just specify portions around each axis to rotate. It actually specifies a normal vector, and an angle around that to rotate. So using something like "1 1 0 1.5" won't rotate you 90 degrees around the x and y axes, it'll rotate you 90 degrees around (1, 1, 0) normalized. Which will leave you with a different result.
09/19/2013 (2:18 pm)
Uh, setPosition is not exposed to scripts. Though if setting .position directly works then that'd be great.Also, I think only the Camera class has a setRotation function. Just be aware.
That 4-element rotation component doesn't just specify portions around each axis to rotate. It actually specifies a normal vector, and an angle around that to rotate. So using something like "1 1 0 1.5" won't rotate you 90 degrees around the x and y axes, it'll rotate you 90 degrees around (1, 1, 0) normalized. Which will leave you with a different result.
#18
Is that right? I only have maths up to AS level (British) so everything beyond basic calculus and geometry is alien to me. I'm also not used to 3d.
EDIT: I hadn't even realised setRotation() existed, and it's still a lot easier to use, but my natural curiosity still makes me want to know the mechanics/maths behind the system - having a full understanding of the engine will expedite development enormously.
EDIT2: Fyi Daniel, position and rotation can be set directly on the camera as the Camera class inherits those attributes as public members from SceneObject. It's all there in the script documentation. :)
EDIT3: And with the help of my new knowledge of the camera object, I've configured it to face the player from above at an edge-on perspective. Now if only I can work out how to switch to axonometric projection. [This might be a joke.] Anyway, it's time for bed before I overwork myself to poor health.
09/19/2013 (3:41 pm)
Ah, so if x, y, and z are portions of the vector, and it rotates around the vector, then the result of "1 1 0 1.5" would be creating a vector (call it e) with the equation [e = x + y] and rotating 90 degrees around that? And "1 1 1 1.5" would rotate 90 degrees around [e = x + y + z]?Is that right? I only have maths up to AS level (British) so everything beyond basic calculus and geometry is alien to me. I'm also not used to 3d.
EDIT: I hadn't even realised setRotation() existed, and it's still a lot easier to use, but my natural curiosity still makes me want to know the mechanics/maths behind the system - having a full understanding of the engine will expedite development enormously.
EDIT2: Fyi Daniel, position and rotation can be set directly on the camera as the Camera class inherits those attributes as public members from SceneObject. It's all there in the script documentation. :)
EDIT3: And with the help of my new knowledge of the camera object, I've configured it to face the player from above at an edge-on perspective. Now if only I can work out how to switch to axonometric projection. [This might be a joke.] Anyway, it's time for bed before I overwork myself to poor health.
#19
Huh, you learn something every day! I'm going to start using .position and .rotation more. I like that better than calling getters and setters!
09/19/2013 (4:50 pm)
You've got the basic idea. It's called axis/angle representation. Take your right hand and point your thumb in the direction of the vector. Now curl your fingers around - that's the direction of rotation around the axis your thumb is pointing. (EDIT: I think. Don't quote me on that :P)Huh, you learn something every day! I'm going to start using .position and .rotation more. I like that better than calling getters and setters!
#20
09/20/2013 (6:02 am)
It sounds arrogant, but has anyone here tried messing around with the field of view using setFov()? (Daniel?) The results are hilarious and weird. Also I can get an orthographic-like projection by lowering the FOV to 20-30 degrees. 
Torque Owner Dan Webb
PsyCandy Games
You should start with this tutorial first, though.