Working on Terrain Manager class...
by Bryan Turner · in Torque Game Engine · 04/04/2002 (9:56 am) · 239 replies
SORRY FOLKS!
Looks like the GORPE updates have fallen off the shelf. I do not have a copy of the most recent TM project, but you are welcome to download my old versions here (pre-Torque 1.2):
www.fractalsacpe.org/TorqueTerrain
www.fractalsacpe.org/TorqueTerrainManager.zip
------------------------------------------------------
Hello again.
I got to working on a Terrain Manager class after digging through the terrain rendering code, and it's coming along nicely.
Basically I took Mark F's suggestions and created a TerrainManager class which is the single point of interface for all terrain functions. Moved the relevent structures to it (Material, BlockSize/Mask/Shift, etc). And stubbed the rest of the functions to point to a TerrainBlock. It hit a lot of files to compile/link, but it's working :)
Now I'm getting to the part where I don't understand..
- Should the TerrainBlock remain a SceneObject? I don't think so, since the TerrainManager should be the only thing in the scene.. But taking this step makes the terrain engine *very* unhappy. I'd like some sort of reassurance that this is the right direction.
- How do I specify a vector of data in the mission file datablocks for things like textures, height map files, etc? Basically I want a datablock for TerrainManager which may contain many TerrainBlock datablocks (which contain resource lists for terrain files, textures, etc..).
Some general terrain engine questions:
- What is a 'square' in the terrain engine, and why does *everyone* need it?
- What is a 'grid block' in the terrain engine? How does it differ from a 'square'?
- What is an MPM (material properties map), and why is it passed around with no encapsulation?
Thanks!
--Bryan
Looks like the GORPE updates have fallen off the shelf. I do not have a copy of the most recent TM project, but you are welcome to download my old versions here (pre-Torque 1.2):
www.fractalsacpe.org/TorqueTerrain
www.fractalsacpe.org/TorqueTerrainManager.zip
------------------------------------------------------
Hello again.
I got to working on a Terrain Manager class after digging through the terrain rendering code, and it's coming along nicely.
Basically I took Mark F's suggestions and created a TerrainManager class which is the single point of interface for all terrain functions. Moved the relevent structures to it (Material, BlockSize/Mask/Shift, etc). And stubbed the rest of the functions to point to a TerrainBlock. It hit a lot of files to compile/link, but it's working :)
Now I'm getting to the part where I don't understand..
- Should the TerrainBlock remain a SceneObject? I don't think so, since the TerrainManager should be the only thing in the scene.. But taking this step makes the terrain engine *very* unhappy. I'd like some sort of reassurance that this is the right direction.
- How do I specify a vector of data in the mission file datablocks for things like textures, height map files, etc? Basically I want a datablock for TerrainManager which may contain many TerrainBlock datablocks (which contain resource lists for terrain files, textures, etc..).
Some general terrain engine questions:
- What is a 'square' in the terrain engine, and why does *everyone* need it?
- What is a 'grid block' in the terrain engine? How does it differ from a 'square'?
- What is an MPM (material properties map), and why is it passed around with no encapsulation?
Thanks!
--Bryan
#122
I was trying to unzip it with WinAce. Its supposed to work. I downloaded the Winrar app and It unzipped fine.
Sorry to bother you.
Matt
12/09/2002 (11:19 am)
OOPSI was trying to unzip it with WinAce. Its supposed to work. I downloaded the Winrar app and It unzipped fine.
Sorry to bother you.
Matt
#123
The only other thing of note in this build is that the green "center terrain" box in the editor now correctly goes around all of the terrain blocks not just the first one.
12/10/2002 (4:06 pm)
I'm putting the finishing touches on build 11. This will be the first release where terrain painting works across all terrain blocks instead of just the first block.The only other thing of note in this build is that the green "center terrain" box in the editor now correctly goes around all of the terrain blocks not just the first one.
#124
Is there some easy way to add this or will I have to manualy work out what needs adding?
12/22/2002 (8:51 pm)
This is just what i need... my only problem is that I have made changes to alot of these files too... if I make a patch file will it just add in the changes or what?Is there some easy way to add this or will I have to manualy work out what needs adding?
#125
I was wondering if there would be any way to make it so that you could seamingly make an endless world with this ?
for example it could load terrain blocks on the fly so you could have say a huge world maybe made up of 25 maps a 5x5 total world where say if you were on block 0,2 that you could walk onto 4,2 with out a problem ?
sorry i may not have understood everything does it do this now ?
12/22/2002 (9:00 pm)
very neat stuff, i haven't tryed it out yet but i will once the holidays are over.I was wondering if there would be any way to make it so that you could seamingly make an endless world with this ?
for example it could load terrain blocks on the fly so you could have say a huge world maybe made up of 25 maps a 5x5 total world where say if you were on block 0,2 that you could walk onto 4,2 with out a problem ?
sorry i may not have understood everything does it do this now ?
#126
12/22/2002 (9:33 pm)
Set up your mission area to surround the 5x5 set, then teleport your player to the other side when he reaches the edge ... that's a simple way.
#127
12/23/2002 (3:06 am)
As with all things torque, what you're proposing is possible it'd just take some work. The 5x5 grid of terrain is easy, after that you'd need to take a look at the terrain repeating code and modify it to wrap around to the same physical blocks instead of repeating virtual versions of them.
#128
12/23/2002 (11:05 am)
repeating the i don't think is a big problem but the on the fly loading would be more so i would belive ... what if i wanted a world 1000x1000 map areas, i don't want them all to load into memory i want just the one your in and maybe the 8 surrounding the one your in. as you move to one of the outer ones that becomes your middle block and it loads the surrounding blocks into memory. Doing this with little or no pause in game play, some examples i can think of are morrowind and dungeon seige that do things like this.
#129
You'd need to do some tricks to make sure that world to grid coordinates get offset properly, I don't imagine you'd want to deal with things like 55,30 suddenly becoming 310, 280 or something. Maybe treat the whole set as one giant grid with a "view port" of the active grid.
You'd need to make sure unused models/textures get unloaded as their associated terrain blocks get unloaded as well.
And I'd imagine that the server would need all blocks in memory at once for bots and the like. Maybe make the view port size configurable through the datablock?
12/23/2002 (3:46 pm)
The actual paging of the terrain wouldn't be too hard, you'd have to redo some calculations that are normaly done once after all the blocks are loaded. You'd need to do some tricks to make sure that world to grid coordinates get offset properly, I don't imagine you'd want to deal with things like 55,30 suddenly becoming 310, 280 or something. Maybe treat the whole set as one giant grid with a "view port" of the active grid.
You'd need to make sure unused models/textures get unloaded as their associated terrain blocks get unloaded as well.
And I'd imagine that the server would need all blocks in memory at once for bots and the like. Maybe make the view port size configurable through the datablock?
#130
For an RPG, it would be trivial to deal with the problem of not having the whole world loaded at once. Just don't do any AI calculations for places the user can't see... After all, how important is it that every merchant's idle walking is accurately modelled 24-7? It never hurt Zelda that when you weren't in the forest, the monsters didn't enact an ecosystem...
In fact, for many single player games, having Large Terrain like this (in conjunction with paging of interiors and related assets) would be immensely useful. How cool would it be if you could model, say, the Philippines, and have your game take place on that? Or Three Mile Island? Or extensive potions of Mars?
As long as you were reasonably clever, the fact that only the 8 nearest chunks of terrain were dealt with in the simulation would make no difference. Say you're writing a bass fishing game, or you want to visualize Cuba, or explore Mars (and try different colonization strategies)... In all these cases, paging support would be immensely useful.
And what of multiplayer? Well, there are many possibilities. For instance, given that the server doesn't need to load in anything beyond some height and material buffers, it might be possible to do context-based paging - ie, the server has in memory the 3x3 chunks of map around every "important" object, like a player or a bot, so that it can do simulations.
This would work well as long as you didn't have 64 players scattered evenly around a huge map. Of course, if you're doing something like an RTS, that might be a problem. No fun building bases next door to your enemy. :)
So in that instance, you either need a really hefty server that can keep the entire map in memory at once (eek!), or you simplify things. One possibility is doing LOD simulations. For instance, if the chunk of map is loaded (for instance, because a player is looking at it), then you model the movement of every unit in full 3d. However, if you don't have the chunk loaded, then you work with an abstract representation of the chunk (like a 2d simplification, or perhaps something more exotic), and do a more abstracted simulation of the game world. For very distant areas, you might just model basic economics and unit distributions...
The downside to this is that it takes a lot more effort to write three distinct simulations that all give compatible results and can be switched freely.
Another, more universally applicable solution would be to build server clustering into the system, a la MMORPGs. Mark sections of the terrain as belonging to different servers, then let stuff pass between them. This would be niftiest, of course, but also potentially hardest to implement, and of course, who wants to cluster a half dozen servers to play the latest RTS... But if you're writing a limited-market, hardcore sim game, that could be acceptable (such as for the people who play tabletop war games or the military, or a convention... things like this.)
But in any case, having paging support in the TM would be really useful for singe player games, even if it couldn't really transition well to multiplayer.
(PS: An addition that some enterprising fellow could add... have the game cache skybox "overlays" for every terrain square. The overlay will be a pre-rendered view of "distant" terrain (say, terrain that's more than one square's distance away) from the center of the square. Then as the camera moves from square to square, switch to different skyboxes. That way you won't have the situation of a large mountain suddenly looming out of the distance fog. Perhaps the skyboxes need to be more closely spaced than per-square - perhaps related to the fog distance.)
12/23/2002 (4:26 pm)
I think that adding paging would be a Neat Feature, but that to be truly useful, some sort of distribution of effort would be needed.For an RPG, it would be trivial to deal with the problem of not having the whole world loaded at once. Just don't do any AI calculations for places the user can't see... After all, how important is it that every merchant's idle walking is accurately modelled 24-7? It never hurt Zelda that when you weren't in the forest, the monsters didn't enact an ecosystem...
In fact, for many single player games, having Large Terrain like this (in conjunction with paging of interiors and related assets) would be immensely useful. How cool would it be if you could model, say, the Philippines, and have your game take place on that? Or Three Mile Island? Or extensive potions of Mars?
As long as you were reasonably clever, the fact that only the 8 nearest chunks of terrain were dealt with in the simulation would make no difference. Say you're writing a bass fishing game, or you want to visualize Cuba, or explore Mars (and try different colonization strategies)... In all these cases, paging support would be immensely useful.
And what of multiplayer? Well, there are many possibilities. For instance, given that the server doesn't need to load in anything beyond some height and material buffers, it might be possible to do context-based paging - ie, the server has in memory the 3x3 chunks of map around every "important" object, like a player or a bot, so that it can do simulations.
This would work well as long as you didn't have 64 players scattered evenly around a huge map. Of course, if you're doing something like an RTS, that might be a problem. No fun building bases next door to your enemy. :)
So in that instance, you either need a really hefty server that can keep the entire map in memory at once (eek!), or you simplify things. One possibility is doing LOD simulations. For instance, if the chunk of map is loaded (for instance, because a player is looking at it), then you model the movement of every unit in full 3d. However, if you don't have the chunk loaded, then you work with an abstract representation of the chunk (like a 2d simplification, or perhaps something more exotic), and do a more abstracted simulation of the game world. For very distant areas, you might just model basic economics and unit distributions...
The downside to this is that it takes a lot more effort to write three distinct simulations that all give compatible results and can be switched freely.
Another, more universally applicable solution would be to build server clustering into the system, a la MMORPGs. Mark sections of the terrain as belonging to different servers, then let stuff pass between them. This would be niftiest, of course, but also potentially hardest to implement, and of course, who wants to cluster a half dozen servers to play the latest RTS... But if you're writing a limited-market, hardcore sim game, that could be acceptable (such as for the people who play tabletop war games or the military, or a convention... things like this.)
But in any case, having paging support in the TM would be really useful for singe player games, even if it couldn't really transition well to multiplayer.
(PS: An addition that some enterprising fellow could add... have the game cache skybox "overlays" for every terrain square. The overlay will be a pre-rendered view of "distant" terrain (say, terrain that's more than one square's distance away) from the center of the square. Then as the camera moves from square to square, switch to different skyboxes. That way you won't have the situation of a large mountain suddenly looming out of the distance fog. Perhaps the skyboxes need to be more closely spaced than per-square - perhaps related to the fog distance.)
#131
The TerrainManager code can now be found in the downloads section of the GORPE project website.
02/05/2003 (5:08 am)
Sorry to bump this but...The TerrainManager code can now be found in the downloads section of the GORPE project website.
#132
02/05/2003 (5:07 pm)
This may be a silly question, but why hasn't this been merged into CVS?
#133
02/06/2003 (2:35 am)
Because it's not yet 100% fully tested and complete. Some things, like new missions, are still a manual proccesses.
#134
www.sickheadgames.com/torque/newmission.zip
This zip contains a new .mis and .ter file to replace the default newMission files so that 'New Mission' in the mission editor doesn't crash the engine. Just unzip the content into the "example\rw\data" folder. A little thing, but it helps Torque newbies like myself.
IMO as adding a little backward compatibility for opening old .mis files is necessary here. I'll see if i can fix this and post my results.
02/06/2003 (9:05 am)
Well here is a little fix then.www.sickheadgames.com/torque/newmission.zip
This zip contains a new .mis and .ter file to replace the default newMission files so that 'New Mission' in the mission editor doesn't crash the engine. Just unzip the content into the "example\rw\data" folder. A little thing, but it helps Torque newbies like myself.
IMO as adding a little backward compatibility for opening old .mis files is necessary here. I'll see if i can fix this and post my results.
#135
> compatibility for opening old .mis
> files is necessary here. I'll see
> if i can fix this and post my results.
Looking at the code it seems to attempt to do this, but it fails when loading Stronghold on the latest HEAD. Looking into it.
02/06/2003 (9:44 am)
> IMO as adding a little backward > compatibility for opening old .mis
> files is necessary here. I'll see
> if i can fix this and post my results.
Looking at the code it seems to attempt to do this, but it fails when loading Stronghold on the latest HEAD. Looking into it.
#136
create TerrainBlock
create TerrainManager
register TerrainBlock
register TerrainManager
which keeps TerrainBlock from hooking up to the right TerrainManager. TerrainManager needs to be registered before any of it's TerrainBlocks.
Also probably an...
... needs to be added to TerrainManager::addTerrainBlock.
Well this seems like it's an error in how the default terrain manager is created. Any ideas?
02/06/2003 (10:11 am)
I figured out why the Stronghold .mis doesn't work. Basically the second TerrainManager that is created ( from a packet to the client? ) doesn't get 'onAdd' called till *after* it's terrain blocks are added. So when getTerrainManager() searches the 'TerrainManagerSet' for the last TerrainManager* it always gets the first one which is the wrong one to add them too. So a single packet comes in with these events...create TerrainBlock
create TerrainManager
register TerrainBlock
register TerrainManager
which keeps TerrainBlock from hooking up to the right TerrainManager. TerrainManager needs to be registered before any of it's TerrainBlocks.
Also probably an...
AssertFatal( nNumTerrain <= ( m_nNumTerrBlocksWide * m_nNumTerrBlocksHigh ), "Added one too many terrain blocks!" );
... needs to be added to TerrainManager::addTerrainBlock.
Well this seems like it's an error in how the default terrain manager is created. Any ideas?
#137
I had some code in there to add a default 1x1 terrain manager if you tried to load an old style mission but somehow broke it last release. This feature may get fixed, but more likely than not it'll get ripped out as soon as we implement creation of multi terrain missions as an automatic process instead of requiring manipulation of the mission file by hand.
02/06/2003 (11:25 am)
Stronghold works fine for me under TerrainManager but I modified the mission file to add a TerrainManager to it. If you've not done so that's probably the source of your problems.I had some code in there to add a default 1x1 terrain manager if you tried to load an old style mission but somehow broke it last release. This feature may get fixed, but more likely than not it'll get ripped out as soon as we implement creation of multi terrain missions as an automatic process instead of requiring manipulation of the mission file by hand.
#138
I downloaded the terrain manager from www.gorpe.com and have a few problems compiling everything... I keep getting errors on the NetGhost.cc file, here are some examples
C:\torque\engine\sim\netGhost.cc(44) : error C2660: 'getClassId' : function does not take 0 parameters
C:\torque\engine\sim\netGhost.cc(45) : error C2660: 'writeClassId' : function does not take 2 parameters
C:\torque\engine\sim\netGhost.cc(54) : error C2660: 'getClassId' : function does not take 0 parameters
C:\torque\engine\sim\netGhost.cc(55) : error C2660: 'writeClassId' : function does not take 2 parameters
C:\torque\engine\sim\netGhost.cc(65) : error C2660: 'readClassId' : function does not take 1 parameters
C:\torque\engine\sim\netGhost.cc(71) : error C2664: 'class ConsoleObject *__cdecl ConsoleObject::create(const char *)' : cannot convert parameter 1 from 'int' to 'const char *'
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
C:\torque\engine\sim\netGhost.cc(224) : error C2065: 'mGhostFrom' : undeclared identifier
I really would like to use the terrain manager on my project so I would like to know if anybody had these errors and if they could be fixed...
Thanks for any help you could give me and for your time.
02/12/2003 (8:56 am)
Hello,I downloaded the terrain manager from www.gorpe.com and have a few problems compiling everything... I keep getting errors on the NetGhost.cc file, here are some examples
C:\torque\engine\sim\netGhost.cc(44) : error C2660: 'getClassId' : function does not take 0 parameters
C:\torque\engine\sim\netGhost.cc(45) : error C2660: 'writeClassId' : function does not take 2 parameters
C:\torque\engine\sim\netGhost.cc(54) : error C2660: 'getClassId' : function does not take 0 parameters
C:\torque\engine\sim\netGhost.cc(55) : error C2660: 'writeClassId' : function does not take 2 parameters
C:\torque\engine\sim\netGhost.cc(65) : error C2660: 'readClassId' : function does not take 1 parameters
C:\torque\engine\sim\netGhost.cc(71) : error C2664: 'class ConsoleObject *__cdecl ConsoleObject::create(const char *)' : cannot convert parameter 1 from 'int' to 'const char *'
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
C:\torque\engine\sim\netGhost.cc(224) : error C2065: 'mGhostFrom' : undeclared identifier
I really would like to use the terrain manager on my project so I would like to know if anybody had these errors and if they could be fixed...
Thanks for any help you could give me and for your time.
#139
02/12/2003 (10:34 am)
Are you using Release_1_1_2 or HEAD? TerrainManager is based on the HEAD source as of a couple months ago so it's possible things have changed out from under it..
#140
02/12/2003 (6:40 pm)
I'm using the latest HEAD version... could be that... thanks 
Torque Owner J. Donavan Stanley
And, no, I don't have a zip version I might look into that but I prefer rar files myself.