Questions about TGEA
by Nathan Kent · in Torque Game Engine · 07/29/2008 (5:14 am) · 7 replies
I have a couple of questions about TGEA before I decide if I want to upgrade to it. I have a limited understanding of some of TGEA's features, so please bear with me.
1. Atlas terrains only have a section loaded at a time, but the engine will load different sections based on where the client is, right? Is there a way to have the engine (Server-side and client-side, this would be a single player game) "think" only about objects that are on the loaded piece of Atlas Terrain? It would be awesome to do my entire RPG world as one Atlas Terrain, but that wouldn't work if I couldn't do that.
2. OK, I admit, both of these are cool, and this question really doesn't effect if I get TGEA. What are the differences between Atlas Terrain, and Mega Terrain. I know Atlas has paging and can't be edited in the engine, but other than that...?
Thanks in advance!
1. Atlas terrains only have a section loaded at a time, but the engine will load different sections based on where the client is, right? Is there a way to have the engine (Server-side and client-side, this would be a single player game) "think" only about objects that are on the loaded piece of Atlas Terrain? It would be awesome to do my entire RPG world as one Atlas Terrain, but that wouldn't work if I couldn't do that.
2. OK, I admit, both of these are cool, and this question really doesn't effect if I get TGEA. What are the differences between Atlas Terrain, and Mega Terrain. I know Atlas has paging and can't be edited in the engine, but other than that...?
Thanks in advance!
About the author
#2
07/29/2008 (6:06 am)
What does "paging" mean, if it doesn't mean loading up pieces of the terrain? 
#3
07/31/2008 (7:04 am)
I would recommend researching ChunkLOD to understand the why's and wherefore's of ATLAS's paged terrain. That was the algorithm that Ben Garney adopted and adapted for terrain chunking. Megaterrains are basically normal Torque terrains that are stitched together. They do not have the detail of ATLAS terrains, but they do have the ability to be edited in-game quickly and easily.
#4
You have the terrain, and it's separated into larger (less detailed) chunks and smaller (more detailed) chunks. The chunks are saved as a file, and the engine will load and render chunks based on the distance from the camera.
Assuming that I'm right, I'll rephrase the question: Is it possible to delay the tick time for objects based on the detail level of the chunk they are on? For example, an AI on a chunk with a low detail has a tick happen 1/4 as often as an AI's on the same chunk as the player, and an AI's who's chunk isn't loaded/has lowest detail doesn't get ticked at all.
Sorry if that last sentence was confusing, it's just one of those days. =P
08/04/2008 (9:36 am)
Ok, here's what I got (that applies to this thread) out of the article I went over:You have the terrain, and it's separated into larger (less detailed) chunks and smaller (more detailed) chunks. The chunks are saved as a file, and the engine will load and render chunks based on the distance from the camera.
Assuming that I'm right, I'll rephrase the question: Is it possible to delay the tick time for objects based on the detail level of the chunk they are on? For example, an AI on a chunk with a low detail has a tick happen 1/4 as often as an AI's on the same chunk as the player, and an AI's who's chunk isn't loaded/has lowest detail doesn't get ticked at all.
Sorry if that last sentence was confusing, it's just one of those days. =P
#5
Remove all code from getMove, instead return a "mLastGeneratedMove". Note I'm making up variable and method names to describe what you might want to do, these do not already exist. In process tick do nothing. In advance time increment a "mElapsedTimeSinceLastProcess", and if "mProcessRate" is elapsed then call "process()" where you generate a move and stick it in "mLastGeneratedMove".
Not sure about the Atlas-chuck part of your question. But assuming you could figure that out, do that test in process() and set mProcessRate higher/lower based on its result.
08/04/2008 (12:26 pm)
I'm not sure how much of the normal AIPlayer code happens in processTick / advanceTime / getMove, but you might do something like this... Remove all code from getMove, instead return a "mLastGeneratedMove". Note I'm making up variable and method names to describe what you might want to do, these do not already exist. In process tick do nothing. In advance time increment a "mElapsedTimeSinceLastProcess", and if "mProcessRate" is elapsed then call "process()" where you generate a move and stick it in "mLastGeneratedMove".
Not sure about the Atlas-chuck part of your question. But assuming you could figure that out, do that test in process() and set mProcessRate higher/lower based on its result.
#6
I'm not to worried about the code to delay the tick, I'm more worried about the Atlas side of things. Probably because I haven't worked with it, and I can't until I get a licence to TGEA. I'm thinking that if I could just get the LOD of the objects chunk, and not call the processTick function.
Actually, I probably should ask these too:
* This would delay all TorqueScript functions too, right?
* Would it be possible to change the Atlas paging system to work with objects (if they are far enough from the player [based on Atlas chunk] write them to a file)? Would it be better to do it that way?
My goal is to have my entire world be one mission, and devote as little resources as possible to objects not in the player's immediate area. I know that this will be a lot of work, and I'd like to see if I could do it, but I need to know if it's even possible or already done by someone.
08/04/2008 (3:18 pm)
So I got ChunkedLOD right? Awesome!I'm not to worried about the code to delay the tick, I'm more worried about the Atlas side of things. Probably because I haven't worked with it, and I can't until I get a licence to TGEA. I'm thinking that if I could just get the LOD of the objects chunk, and not call the processTick function.
Actually, I probably should ask these too:
* This would delay all TorqueScript functions too, right?
* Would it be possible to change the Atlas paging system to work with objects (if they are far enough from the player [based on Atlas chunk] write them to a file)? Would it be better to do it that way?
My goal is to have my entire world be one mission, and devote as little resources as possible to objects not in the player's immediate area. I know that this will be a lot of work, and I'd like to see if I could do it, but I need to know if it's even possible or already done by someone.
#7
It does load pieces of the terrain and Atlas is also completely capable of fully paging terrains. The reason it does not do this for the highest LOD is that it needs this data for collision detection. Also note that the paging features of Atlas extend to more than just geometry.
Yes, it's possible. You'd have to do all the object work synchronously on the main thread, though, as Torque's engine core isn't multithread-safe. As a whole, it doesn't look like the best approach to me. Your world probably would also have to be really, really big for this to pay off and Atlas certainly would not be a viable solution per se then (assuming you have a player on-surface and need some landscape detail around him/her).
08/08/2008 (12:18 am)
Finding the chunk LOD underneath an object would require some custom coding. There's already code to do ray/bbox collision the result of which then would have to be used for walking the quadtree upwards to find the first unsplit node. The splitting state gets reset each frame, so the accuracy of the result depends on whether you are running after or before Atlas' rendering code--that shouldn't matter much in case of the delay stuff, though (except during the first frame of course).Quote:What does "paging" mean, if it doesn't mean loading up pieces of the terrain?
It does load pieces of the terrain and Atlas is also completely capable of fully paging terrains. The reason it does not do this for the highest LOD is that it needs this data for collision detection. Also note that the paging features of Atlas extend to more than just geometry.
Quote:* Would it be possible to change the Atlas paging system to work with objects (if they are far enough from the player [based on Atlas chunk] write them to a file)? Would it be better to do it that way?
Yes, it's possible. You'd have to do all the object work synchronously on the main thread, though, as Torque's engine core isn't multithread-safe. As a whole, it doesn't look like the best approach to me. Your world probably would also have to be really, really big for this to pay off and Atlas certainly would not be a viable solution per se then (assuming you have a player on-surface and need some landscape detail around him/her).
Torque 3D Owner Edward