How are the graphics processed by the clients?
by Jonathon Stevens · in Torque Game Engine · 03/31/2006 (12:39 pm) · 5 replies
I have no clue what to exactly 'term' this question, and therefore searching for the answers became rather grueling and uneventful. Please point me to another thread if this is answered elsewhere and I apologise for asking it again if it's a common question.
Let me explain a little about why I want to know this question and then I'll get to the actual question. I'm wanting to create zones in my worlds. Each zone would reside on it's own dedicated server. I want to be able to pass the player from zone to zone without EVER stopping to load. My network guy said this should be easy as the client processes the graphics, not the server, so passing the client from server to server shouldn't affect loading of zones. When they get near a zone, you load it in the background and then hand them off when you get there.
So, my question would be, how are the graphics rendered to the client in TGE? Do they render only what's visable to the player or the entire zone all at once? If they load the entire zone all at once, what's to stop me from just loading that zone in the background when players get close enough to want to go to the other zone?
Let me explain a little about why I want to know this question and then I'll get to the actual question. I'm wanting to create zones in my worlds. Each zone would reside on it's own dedicated server. I want to be able to pass the player from zone to zone without EVER stopping to load. My network guy said this should be easy as the client processes the graphics, not the server, so passing the client from server to server shouldn't affect loading of zones. When they get near a zone, you load it in the background and then hand them off when you get there.
So, my question would be, how are the graphics rendered to the client in TGE? Do they render only what's visable to the player or the entire zone all at once? If they load the entire zone all at once, what's to stop me from just loading that zone in the background when players get close enough to want to go to the other zone?
About the author
With a few casual games under his belt as CEO of Last Straw Productions, Jonathon created the increasingly popular Indie MMO Game Developers Conference.
#2
03/31/2006 (1:05 pm)
So really what I'm trying to do should be simple, as the entire zone isn't loaded at once. Just where you are and based on those three things. The server just knows what your location is and everyone else's location. So it just tells the client #1 what zone it's in and where in that zone it is, and let the client take care of what to render and where. This sound right?
#3
To put it simply: while moving around the client connection sends scopeQuery calls to the server connection, specifying a query position (usually the camera position). The server will then look for objects around that position whithin scope range that aren't ghosted already, and them make these objects send their ghosts to the server.
A ghost is a client-side instance of an object that exists in the server. Each client connection stores a list of "ghostIDs", that are updated when new objects are ghosted. This list is mirrored on the server, so the server can known the ghostID for a given server-side object in a given client's side. Based on this, when the server-side object needs to send some information to the clients, the server connection can route the information to each client where that object was ghosted, and the client can update the information of the correct object.
The "way clients process graphics" is just that only the client-side ghosts get their render methods called, by the client-side scenegraph. This is a most automatic method, so you'll need to concentrate your efforts in finding a way to have a client connect to two servers at the same time, somehow.
I believe the ghosts will all die, or get "orphaned", if you switch the connection from a server to another, since the objects in the other server will have completly different IDs. If you really don't want to destroy all ghosts and create new ones based on the new server's objects, you'll need to find a way to re-associate ghosts to objects in another server.
04/01/2006 (2:16 pm)
Actually, there's more worms in that can. I strongly advice you to read everything you can find in the TDN about the client/server model and the ghosting system.To put it simply: while moving around the client connection sends scopeQuery calls to the server connection, specifying a query position (usually the camera position). The server will then look for objects around that position whithin scope range that aren't ghosted already, and them make these objects send their ghosts to the server.
A ghost is a client-side instance of an object that exists in the server. Each client connection stores a list of "ghostIDs", that are updated when new objects are ghosted. This list is mirrored on the server, so the server can known the ghostID for a given server-side object in a given client's side. Based on this, when the server-side object needs to send some information to the clients, the server connection can route the information to each client where that object was ghosted, and the client can update the information of the correct object.
The "way clients process graphics" is just that only the client-side ghosts get their render methods called, by the client-side scenegraph. This is a most automatic method, so you'll need to concentrate your efforts in finding a way to have a client connect to two servers at the same time, somehow.
I believe the ghosts will all die, or get "orphaned", if you switch the connection from a server to another, since the objects in the other server will have completly different IDs. If you really don't want to destroy all ghosts and create new ones based on the new server's objects, you'll need to find a way to re-associate ghosts to objects in another server.
#4
Well:
--currently, Torque zones are loaded all at once--it's just that only objects in scope are delivered. This does however imply that there is a "load zone" wait state that would need to be modified
--making Torque threadsafe (probably 3-6 months of work depending on your experience level with multi-threaded applications) enough to allow for background loading--NOTE: it can be done, but it takes work
--writing the background zone loader itself (another 1-4 months, see above)
--analyzing, designing, and implementing your hueristics for what "close enough" is (anywhere from 2-9 months, again depending on your team and knowledge base)
----avoiding thrashing
----allowing for cross-server ghosting, ghost management handoffs, and "through server" ghosting
----allow for server to server migration of client connections, as well as server side objects
That's just getting started, too. It really is a very complex problem.
04/02/2006 (1:06 pm)
@Jonathon: Please don't take this the wrong way, but both you and your networking guy are being rather naive as to the complexity of streaming/"zoneless" networking in a 3D world environment...Quote:
what's to stop me from just loading that zone in the background when players get close enough to want to go to the other zone?
Well:
--currently, Torque zones are loaded all at once--it's just that only objects in scope are delivered. This does however imply that there is a "load zone" wait state that would need to be modified
--making Torque threadsafe (probably 3-6 months of work depending on your experience level with multi-threaded applications) enough to allow for background loading--NOTE: it can be done, but it takes work
--writing the background zone loader itself (another 1-4 months, see above)
--analyzing, designing, and implementing your hueristics for what "close enough" is (anywhere from 2-9 months, again depending on your team and knowledge base)
----avoiding thrashing
----allowing for cross-server ghosting, ghost management handoffs, and "through server" ghosting
----allow for server to server migration of client connections, as well as server side objects
That's just getting started, too. It really is a very complex problem.
#5
I know that didn't add much - just felt like posting. XD
04/02/2006 (2:20 pm)
Good luck man. Sounds like a 3D version of IRC.I know that didn't add much - just felt like posting. XD
Torque Owner AllynMcelrath
Visability (some what LOS)
Distance (distace culling)
Fog (fog used in missions to obscure things before the distance kicks in)