Are these modifications possible? List inside)
by __._ · in Torque Game Engine · 03/01/2007 (1:23 am) · 21 replies
I'm currently part of a (non-commercial) project that will teach children more about technology. Part of this involves a story and to not bore you with that part: at the end children can take place on a motion simulator that will allow them to fly freely over/through the 3D world of the story and perform some tasks.
To create this 3D world we would like to use the Torque Engine (1.5, plus the CG Dynamic Gamma & Water Upgrade), but there are some issues I am not sure Torque can handle. I am hoping to find out here if the following items are at all possible, and hopefully how I build them into Torque.
- The world will be projected using 4 camera's, 3 in a cone in front of the players, and 1 below, showing the what they are flying over at the moment. Can this be achieved? The thought came to me to use Torque's networking system and make the remaining 3 camera's spectators with a modified viewing angle, but I'm not sure this is even possible.
- The motion simulator would need to receive data from the Torque engine, mainly rotation etc. The interface itself or programming the output signal in C++ isn't problem, but how/where can we make Torque send out this data?
I hope you can shed some light on these matters and help us implement these changes if at all possible. If this works it can boost Torque's reputation even higher. The alternative would be to build an engine from scratch, but that will take too much time.
To create this 3D world we would like to use the Torque Engine (1.5, plus the CG Dynamic Gamma & Water Upgrade), but there are some issues I am not sure Torque can handle. I am hoping to find out here if the following items are at all possible, and hopefully how I build them into Torque.
- The world will be projected using 4 camera's, 3 in a cone in front of the players, and 1 below, showing the what they are flying over at the moment. Can this be achieved? The thought came to me to use Torque's networking system and make the remaining 3 camera's spectators with a modified viewing angle, but I'm not sure this is even possible.
- The motion simulator would need to receive data from the Torque engine, mainly rotation etc. The interface itself or programming the output signal in C++ isn't problem, but how/where can we make Torque send out this data?
I hope you can shed some light on these matters and help us implement these changes if at all possible. If this works it can boost Torque's reputation even higher. The alternative would be to build an engine from scratch, but that will take too much time.
#2
03/01/2007 (11:18 am)
So 1 client can render 4 viewpoints to 4 different screens? Would this take 2 dual-head videocards for 4 screens or am I wrong?
#3
03/01/2007 (11:50 am)
You need source code changes depending on what exactly you want--and with source code changes, you can do whatever you have the skills for. 
#4
I would think it would be simpler to have four clients, each rendering a different view, but then you are increasing your hardware requirements. Depending on how the motion control rig is designed, that may not be an issue, or it could be a huge stumbling block. Rendering from one client would be a good chunk of coding, and would require multihead/multicard setups for sure...
You can see more information about the project I worked on (MRC) at my site.
If you get going on this, and run into any issues, feel free to drop me a line and I'll see if I can lend some advice...
Eric
03/01/2007 (12:20 pm)
I worked on a motion simulator ride using Torque a few years back. I created a custom class for sending and receiving the data packets from the motion control software. It was actually pretty easy to get that part working. We only had one screen, so we didn't have deal with the other part, though that should be possible.I would think it would be simpler to have four clients, each rendering a different view, but then you are increasing your hardware requirements. Depending on how the motion control rig is designed, that may not be an issue, or it could be a huge stumbling block. Rendering from one client would be a good chunk of coding, and would require multihead/multicard setups for sure...
You can see more information about the project I worked on (MRC) at my site.
If you get going on this, and run into any issues, feel free to drop me a line and I'll see if I can lend some advice...
Eric
#5
all running fullscreen resolution.
what type of things will they be rendering?
you might be facing some performance issues.
this sounds like fun to implement tho!
Edit:
did not read it close enough. sorry.
as mentioned the networking socket messaging should fullfill your needs here.
sticking to a mutliple instance scenario would definately be my choice.
I would use networking to perform the messaging between the clients and the sim.
the code modifications to support multiple viewports from one client, will probably not bring you much if any performance benefits.
03/01/2007 (1:32 pm)
4 seperate windows.all running fullscreen resolution.
what type of things will they be rendering?
you might be facing some performance issues.
this sounds like fun to implement tho!
Edit:
did not read it close enough. sorry.
as mentioned the networking socket messaging should fullfill your needs here.
sticking to a mutliple instance scenario would definately be my choice.
I would use networking to perform the messaging between the clients and the sim.
the code modifications to support multiple viewports from one client, will probably not bring you much if any performance benefits.
#6
I'm not making any choices yet technology-wise, but for all I care, I will use 4 different PC's to render the 4 displays, at this time anything goes. I personally (as main coder) have plenty of C++ experience, but hardly any experience modifying Torque's source, so at some point I might need a finger to point me in the right direction.
03/01/2007 (11:27 pm)
Thank you for all your input, and if there's more, please keep it coming ;)I'm not making any choices yet technology-wise, but for all I care, I will use 4 different PC's to render the 4 displays, at this time anything goes. I personally (as main coder) have plenty of C++ experience, but hardly any experience modifying Torque's source, so at some point I might need a finger to point me in the right direction.
#7
Here's how I would do it:
Make sure that the first client to connect is the Master. So it's camera looks straight fwd.
All the other clients receives the camera transform, and then changes it to look in a different direction. Because you will (Should) be doing this over a LAN, you can just update the network settings (UpdateRate, etc) To make sure it's smooth.
Basically when you now control the "Master" player/vehicle/whatever, the other clients will just follow, and update their rotation on the camera.
This could be a very interesting project. Imagine having a demo of your game have multiple screens... Or sitting in a sphere playing a Air Ace, where you can actually turn your head back and see who's attacking you. That woul be a costly setup though :-P
03/09/2007 (12:55 am)
I think it that it wouldnt be too hard with 4 Pc's.Here's how I would do it:
Make sure that the first client to connect is the Master. So it's camera looks straight fwd.
All the other clients receives the camera transform, and then changes it to look in a different direction. Because you will (Should) be doing this over a LAN, you can just update the network settings (UpdateRate, etc) To make sure it's smooth.
Basically when you now control the "Master" player/vehicle/whatever, the other clients will just follow, and update their rotation on the camera.
This could be a very interesting project. Imagine having a demo of your game have multiple screens... Or sitting in a sphere playing a Air Ace, where you can actually turn your head back and see who's attacking you. That woul be a costly setup though :-P
#8
03/09/2007 (5:53 am)
I will let you know about my progress =) Next week I'm starting with some prototypes, though those will be boring for you (creating a flying player, modifying camera codes so I can have cutscene-like behaviour for the camera's etc.)
#9
Is this all there is to it (will Torque's source allow this) ? If so, in which file do I look?
03/09/2007 (10:10 am)
On Gamedev.net it has been suggested I do the following to extend Torque across 4 different screens:Quote:
Just make one large window, create a context over it. Then split the window up into four separate sections, there is a NeHe tutorial on this actually (splitting it into 4, not multiple monitors as that doesn't matter).
Is this all there is to it (will Torque's source allow this) ? If so, in which file do I look?
#10
Rather than just tweaking code, though, for some of the things you want to do, you will be writing a large portion of new C++ code and interfacing it with the engine.
03/09/2007 (10:15 am)
Well, if you're an OpenGL programmer, then the Nehe tutorial will help you out quite a lot. But you will also need to make sure that you interface with it correctly within Torque. Implementing Multiple Viewports and updating it to 1.5 might be a better way to go.Rather than just tweaking code, though, for some of the things you want to do, you will be writing a large portion of new C++ code and interfacing it with the engine.
#11
I haven't even toyed with it yet, but I'm leaning towards the multiple computer route, as I'm thinking the framerate is going to take a major hit with a single computer/GPU rendering the multiple viewports, even using SLI mode its still going to take a bit of a performance hit.
I'm just hoping that lag doesnt introduce and problems updating the client views, hopefully if they're running off the same switch it should be fine. My 2 cents anyway.
03/12/2007 (4:23 am)
I'm thinking of going to be going down the multiple viewports path as I want to eventually design a sit-down cockpit arrangement. I haven't even toyed with it yet, but I'm leaning towards the multiple computer route, as I'm thinking the framerate is going to take a major hit with a single computer/GPU rendering the multiple viewports, even using SLI mode its still going to take a bit of a performance hit.
I'm just hoping that lag doesnt introduce and problems updating the client views, hopefully if they're running off the same switch it should be fine. My 2 cents anyway.
#12
But, even when it works, how would you calculate how much to rotate the camera? Won't this method result in 3 displays that don't connect seemlesly with each other? Not sure how to explain it..
03/12/2007 (6:38 am)
So basically have 4 computers, 1 of which is running a player controlled client, and the other 3 are in spectator mode... is this available out of the box? But, even when it works, how would you calculate how much to rotate the camera? Won't this method result in 3 displays that don't connect seemlesly with each other? Not sure how to explain it..
#13
If all four computers running in the same LAN - you can have from minor to none lags at all, increasing packet size and rate to send netpackets.
03/12/2007 (6:46 am)
RJ, what you describe is possible using Torque, but not stock. You need to change the code, so "other" 3 computer will connect as spectators (cameraObject) and these cameras need to be attached with needed offset/angle (this can be pre-set on "main" computer -ala server, that will control clients). All the rest is covered by engine.If all four computers running in the same LAN - you can have from minor to none lags at all, increasing packet size and rate to send netpackets.
#14
03/12/2007 (10:47 am)
While not "stock", I'm reasonably sure that all of what bank mentions can be done in script--I'd have to check it out to make sure, but it's a matter of tracking which 'type' of client is connecting, and if it's a subsidiary (not directly controlled) camera view client, using a camera node from the main control client.
#15
That part I don't really get, you suggest to make a model with more then 1 camera node, and then select which node to use? If so I have no idea how to select it :$
03/12/2007 (10:51 am)
Quote:
using a camera node from the main control client.
That part I don't really get, you suggest to make a model with more then 1 camera node, and then select which node to use? If so I have no idea how to select it :$
#16
I would suggest that you focus on the more basic aspects of getting things working, learning how Torque and TorqueScript work along the way, and then you can move on to the more advanced/unusual functionality of your game.
While not difficult, this type of display system is a bit complex. You'll have to do several things:
--modify your model to have multiple named camera nodes
--when the "main control client" connects, create multiple camera objects, one for each of the nodes
--track on the server the set of control objects, and their clients
--when a non-control client (side view) connects, indicate that is what they are, and for which main control client they are viewing for
--in their ::onClientEnterGame(), instead of setting the control object to a "new" object, set it to the appropriate camera object placement for the appropriate main control object
--filter out their input moves so they cannot (or maybe they can--change camera rotation maybe without movement, etc, etc) modify their control object directly.
That's just one direction for implementation by the way-- and off the top of my head. There are probably many other ways of implementing it depending on what you finally want as your gameplay functionality.
03/12/2007 (11:15 am)
Humble suggestion, and please don't take it offensively:I would suggest that you focus on the more basic aspects of getting things working, learning how Torque and TorqueScript work along the way, and then you can move on to the more advanced/unusual functionality of your game.
While not difficult, this type of display system is a bit complex. You'll have to do several things:
--modify your model to have multiple named camera nodes
--when the "main control client" connects, create multiple camera objects, one for each of the nodes
--track on the server the set of control objects, and their clients
--when a non-control client (side view) connects, indicate that is what they are, and for which main control client they are viewing for
--in their ::onClientEnterGame(), instead of setting the control object to a "new" object, set it to the appropriate camera object placement for the appropriate main control object
--filter out their input moves so they cannot (or maybe they can--change camera rotation maybe without movement, etc, etc) modify their control object directly.
That's just one direction for implementation by the way-- and off the top of my head. There are probably many other ways of implementing it depending on what you finally want as your gameplay functionality.
#17
03/12/2007 (11:28 am)
No offense taken. And I have to admit, though in theory it all makes sense to me, I lack the practical experience to do the things you listed. For example, I see where and how Torque creates a camera when a client enters the game, but I don't see how it is connected to the node made in 3D Max. This presents a problem as the project mentioned in the first post should be finished in June, this won't allow me to get to know Torque inside out (as I have 2 more projects right now). Pherhaps someone can suggest a different solution?
#18
And a LOT of C++ coding.
03/12/2007 (11:33 am)
You could search for open-source project that have the precise elements that you need and use Ogre as a rendering front-end.And a LOT of C++ coding.
#19
Have a look at engine/game/shapeBase.cc, in the ShapeBaseData::preload() you can see
P.S. David, yes, it's possible to use Ogre for rendering, but then - he need to get other stuff all together - physics, networks, etc. No any other engine (except TGE/A)have "Torque Network" integrated :)
03/12/2007 (12:54 pm)
RJ, it doesn't matter what you choose, you need to hack into C++ code of engine if you need to achieve things you need.Have a look at engine/game/shapeBase.cc, in the ShapeBaseData::preload() you can see
cameraNode = shape->findNode("cam");Looking further for dealing with the camera object itself, and following the direction Stephen said, you can get the most you need. Just spend some time looking at the sources and understanding on how the camera and player control handled by engine - then you it will be much more easier for you to decide what to do. And, yeah, there could be many different ways of implementation. Other interesting "places" to have a look om /engine/game/ - gameConnectionMoves.cc, player.cc and camera.cc - running doxyGen on sources can give you really nice pages to see all classes and other info. Good luck.P.S. David, yes, it's possible to use Ogre for rendering, but then - he need to get other stuff all together - physics, networks, etc. No any other engine (except TGE/A)have "Torque Network" integrated :)
#20
03/12/2007 (2:55 pm)
I know, but for his timeline, learning the engine and cobbling what he needs together may be too big of a project. Cobbling together his needs by June and starting from scratch might save him some time, though be less stable down the road. 
Torque 3D Owner Stephen Zepp
Torque can easily communicate with external applications, including simulators, either through TCP/IP (TCPObject), UDP (Torque Networking--requires integration of Torque Networking with the external application), or custom solutions. Once you learn about how event management works in Torque, you can easily create new events, and create methods to pass information to external applications.