Sign up to revive Terrain Manager
by David Dougher · in Torque Game Engine · 05/21/2004 (7:07 am) · 59 replies
The Terrain Manager and Gorpe have pretty much gone away as a result of apathy on the part of the community. Lots of people wanted to the code but no one was willing to make improvements to it. If you are interested in reviving it AND you are willing to contribute to make it a viable base for further development sign up below so GG can see you are interested.
No guarantees here folks. I don't work for GG. But at least this will give them a place to guage customer interest. If nothing else, maybe it will encourage them to consider it as an add-on to TSE! ;)
No guarantees here folks. I don't work for GG. But at least this will give them a place to guage customer interest. If nothing else, maybe it will encourage them to consider it as an add-on to TSE! ;)
About the author
Owner - Pariah Games, Adjunct Professor - Bristol Community College, Mentor - Game Design - Met School Newport, Mentor - Game Design - Met School Providence
#22
One of the most annoying problems I ran into when first working with the Terrain Manager engine was that of importing grey scale heightmaps. Our artists created a grey scale map of the game world we wanted and then we imported it by breaking it up into individual 256x256 tiles.
If you imported a single tile it would read the tile in and you could edit it or just export it out and it would be fine. However, after the scaling that torque was doing on import, the tiles would never properly realign to create seamless terrain.
If you are looking for an acid test for the creation for seamless terrains might I suggest you create a large greyscaled image with a wide ranging set of mountains and valleys, cut it into 256x256 blocks and import them individually into TSE make some changes to the middle of each terrain block, save them and then see if they can still be made to fit together seamlessly taken as a group.
The alternative of course would be to be able to specify reading in a series of greyscale maps and match them up as they are read for a single import, but that would be a whole new can of worms and doesn't necessarily address the issues of people who made their tiles by dividing, importing, customizing and then trying to join them as I described above.
The latter is something I hope to allow the art team to do, since they have divided themselves along cultural lines and territories for our game.
Oh and for the record. Tim G. says that GG "owes me one" for a recent favor. I owe you SEVERAL for this and probably a case of your favorite beverage to boot. I am sure that several other people here feel the same way. This is a major accomplishment in the flexability of the next generation of torque.
Thanks.
05/25/2004 (8:47 am)
Ben,One of the most annoying problems I ran into when first working with the Terrain Manager engine was that of importing grey scale heightmaps. Our artists created a grey scale map of the game world we wanted and then we imported it by breaking it up into individual 256x256 tiles.
If you imported a single tile it would read the tile in and you could edit it or just export it out and it would be fine. However, after the scaling that torque was doing on import, the tiles would never properly realign to create seamless terrain.
If you are looking for an acid test for the creation for seamless terrains might I suggest you create a large greyscaled image with a wide ranging set of mountains and valleys, cut it into 256x256 blocks and import them individually into TSE make some changes to the middle of each terrain block, save them and then see if they can still be made to fit together seamlessly taken as a group.
The alternative of course would be to be able to specify reading in a series of greyscale maps and match them up as they are read for a single import, but that would be a whole new can of worms and doesn't necessarily address the issues of people who made their tiles by dividing, importing, customizing and then trying to join them as I described above.
The latter is something I hope to allow the art team to do, since they have divided themselves along cultural lines and territories for our game.
Oh and for the record. Tim G. says that GG "owes me one" for a recent favor. I owe you SEVERAL for this and probably a case of your favorite beverage to boot. I am sure that several other people here feel the same way. This is a major accomplishment in the flexability of the next generation of torque.
Thanks.
#23
Does that mean that each terrain block can have a different detail map?
ie. have a dirt detail on one block and a grass detail on another block.
05/25/2004 (8:55 am)
Thanks for the response Ben. Just 1 more question about the terrain. When you say :Quote: It lets you load multiple terrain blocks and have them be part of the same terrain, so that your effective terrain area is greater than the default 256x256.
Does that mean that each terrain block can have a different detail map?
ie. have a dirt detail on one block and a grass detail on another block.
#24
interested in a Terrain Paging System
for TGE.
A server-side option capable of paging multiple terrain blocks to the Clients.
The last thing I read on Terrain Manager was work being done so it could page terrain to clients.
Terrain Manager:
Manages multiple terrain blocks in memory to hold more than a single 256x256 terrain block.
Terrain Paging System:
Pages Multiple terrain blocks to clients who cannot hold a lot in memory but can manage a single 256x256 terrain block.
So when a client leaves the boundaries of one block the new one is ready to be render into the clients view.
So would it be easier to introduce paging to TGE "Terrain Manager"?
or would it be easier to introduce paging to TSE updated Terrain engine because it handles terrain better.
Either way I got no problems rendering a planet-size levels full of nothing because Iam crazy like that :)
John H. :)
05/25/2004 (9:27 am)
:) Ok what about just saying anyoneinterested in a Terrain Paging System
for TGE.
A server-side option capable of paging multiple terrain blocks to the Clients.
The last thing I read on Terrain Manager was work being done so it could page terrain to clients.
Terrain Manager:
Manages multiple terrain blocks in memory to hold more than a single 256x256 terrain block.
Terrain Paging System:
Pages Multiple terrain blocks to clients who cannot hold a lot in memory but can manage a single 256x256 terrain block.
So when a client leaves the boundaries of one block the new one is ready to be render into the clients view.
So would it be easier to introduce paging to TGE "Terrain Manager"?
or would it be easier to introduce paging to TSE updated Terrain engine because it handles terrain better.
Either way I got no problems rendering a planet-size levels full of nothing because Iam crazy like that :)
John H. :)
#25
Initially terrain paging was to be on the client only, but the server would hold the whole game world. There would be a 3x3 client paging system. I wrote the code (with Fredrik Svennson) for the initial trial which required that you specify the maxtile size of the game world (a hardcoded value we hoped to elminate later) and provide the NxM tile size as part of the load process. The paging was to be a 3x3 tile set with you in the middle tile. The paging only occurred on the client side This was possible because a dedicated server did not have the textures overhead of the client.
There was a provision being worked on to stream local objects from the server to the client. The idea was that objects could be labeled as "load locally" when you were near an object, "load on entering the tile" for larger objects, and "load when paging" for really big things that could be seen more than a tile away. To support that XML was added.
But I never heard of any plan that it was going to stream tile blocks from the server or instruct the client to load them from disk other than thru the paging mechanism.
There was a thought to stream all changed tile blocks from the server to the client's disk as a patch mechanism, but this would only have occurred at the start of game play. Was this what you were thinking?
05/25/2004 (9:43 am)
Hmmm. Johnny, that wasn't in Gorpe or in the Terrain Manager. Initially terrain paging was to be on the client only, but the server would hold the whole game world. There would be a 3x3 client paging system. I wrote the code (with Fredrik Svennson) for the initial trial which required that you specify the maxtile size of the game world (a hardcoded value we hoped to elminate later) and provide the NxM tile size as part of the load process. The paging was to be a 3x3 tile set with you in the middle tile. The paging only occurred on the client side This was possible because a dedicated server did not have the textures overhead of the client.
There was a provision being worked on to stream local objects from the server to the client. The idea was that objects could be labeled as "load locally" when you were near an object, "load on entering the tile" for larger objects, and "load when paging" for really big things that could be seen more than a tile away. To support that XML was added.
But I never heard of any plan that it was going to stream tile blocks from the server or instruct the client to load them from disk other than thru the paging mechanism.
There was a thought to stream all changed tile blocks from the server to the client's disk as a patch mechanism, but this would only have occurred at the start of game play. Was this what you were thinking?
#26
There are no detail textures anymore. That was a fixed function hack. It's all rendered using shaders, so if you want a detail texture, just set up a material in TSE to do it...
@David:
I haven't gotten to the "niceties" like loading greyscale heightmaps yet. I think the simplest solution would be for the user to supply one big heightmap, which the terrain code would simply slice up and tile as needed. Having to pre-dice-and-slice heightmaps is silly... Obviously, the bitmap code may not be happy if you try to load a 16k by 16k PNG. :) We'll need to find a solution for that at some point.
I'm not at the phase where I'm doing work with the editor or importing yet. But when I do I'll keep your suggestion in mind. I think that this is a rare opportunity to dramatically streamline the terrain workflow.
05/25/2004 (9:45 am)
@Michael:There are no detail textures anymore. That was a fixed function hack. It's all rendered using shaders, so if you want a detail texture, just set up a material in TSE to do it...
@David:
I haven't gotten to the "niceties" like loading greyscale heightmaps yet. I think the simplest solution would be for the user to supply one big heightmap, which the terrain code would simply slice up and tile as needed. Having to pre-dice-and-slice heightmaps is silly... Obviously, the bitmap code may not be happy if you try to load a 16k by 16k PNG. :) We'll need to find a solution for that at some point.
I'm not at the phase where I'm doing work with the editor or importing yet. But when I do I'll keep your suggestion in mind. I think that this is a rare opportunity to dramatically streamline the terrain workflow.
#27
05/25/2004 (10:15 am)
:) That is very cool to know. I'm looking forward to this.
#28
Sounds really good. We're meeting in the middle design wise, and that always makes a project manager happy, lol. Now I'm -really- looking forward (again) to seeing the new TSE terrain work! I'm glad as well that you recognize the workflow pipeline of chopping up a large world into "game edible" pieces, it's a rough one to manage.
@David: We're working on a very similar design (we call it a 9grid) for "server to client" preloading of expected terrain and objects. If your (or the old gorpe?) code is available, it would be really nice to take a peek at and see if what we're thinking has been (at least) partially worked on.
@Johnny: Thanks, hehe...it's rough sometimes when terms have different meanings at different levels of work!
05/25/2004 (10:15 am)
@Ben: (sings) "You make me so, very happy!" (hehe..anyone know that song? it's REALLY old!)Sounds really good. We're meeting in the middle design wise, and that always makes a project manager happy, lol. Now I'm -really- looking forward (again) to seeing the new TSE terrain work! I'm glad as well that you recognize the workflow pipeline of chopping up a large world into "game edible" pieces, it's a rough one to manage.
@David: We're working on a very similar design (we call it a 9grid) for "server to client" preloading of expected terrain and objects. If your (or the old gorpe?) code is available, it would be really nice to take a peek at and see if what we're thinking has been (at least) partially worked on.
@Johnny: Thanks, hehe...it's rough sometimes when terms have different meanings at different levels of work!
#29
@Stephen: Indies share. It helps offset the development costs that the big guys can spend and we can't... ;)
I'll e-mail you and we can work out some way for you to see what we've got. Interested to see what you came up with as well...
05/25/2004 (10:26 am)
@Ben: You're welcome to the suggesiton, and I look forward to see what you come up with.@Stephen: Indies share. It helps offset the development costs that the big guys can spend and we can't... ;)
I'll e-mail you and we can work out some way for you to see what we've got. Interested to see what you came up with as well...
#31
Chicago
05/25/2004 (7:43 pm)
Quote:
@Ben: (sings) "You make me so, very happy!" (hehe..anyone know that song? it's REALLY old!)
Chicago
#33
You load 16 tons and what do you get?
Another day older and deeper in debt
Satan don't you call me cause I can't go.
I owe my soul to the company store....
A considerably older song. Nowadays it always makes me think of coding under Microsoft Windows... hee hee.
05/26/2004 (4:45 am)
Nice one. More fun. Who crooned the lines...You load 16 tons and what do you get?
Another day older and deeper in debt
Satan don't you call me cause I can't go.
I owe my soul to the company store....
A considerably older song. Nowadays it always makes me think of coding under Microsoft Windows... hee hee.
#34
05/26/2004 (5:22 am)
Just wanted to chime in that I'm very interested in this, and see it as a great asset to Torque in general. I can't however, contribute with any code, since I'm not a coder :( 
#35
05/26/2004 (6:42 am)
@David: I seem to remember Tennessee Ernie Ford signing that song, but there may have been others (yes I'm that old :))
#36
05/26/2004 (6:59 am)
Right in one! And I'm that old too. LOL. Still have an old vinyl album with it around here somewhere. On the other hand, I think I also have a single-sided 78 Album of the Ave Maria. That's old! It had a giant chip missing and it came from my grandmother's old Victrola but it was the coolest thing I ever remember finding as a kid - a record album that was only recorded on one side. And except for the chunk missing it still played beautifully. Of course, with a vinyl record almost a 16th of an inch thick you would expect it to have some staying power...
#37
05/26/2004 (7:13 am)
Sorry double post.
#38
"Stars on 45".
:-)
05/26/2004 (7:33 am)
Heh, used to have some 78's - dunno what happened to them. Went looking for them after reading the above, and guess what I found ?"Stars on 45".
:-)
#39
05/27/2004 (12:47 pm)
David, Count me in -- I just started to work on this again
#40
Do you have a recent copy of Gorpe and/or Terrain Manager? If necessary I can provide you a copy. I think everybody here is pretty clear that you are a torque owner by now...
05/27/2004 (4:56 pm)
Ok Desmond.Do you have a recent copy of Gorpe and/or Terrain Manager? If necessary I can provide you a copy. I think everybody here is pretty clear that you are a torque owner by now...
Associate Kyle Carter
Glad we got this cleared up. :)
@Michael:
I don't know what more to say about it. It's just like GORPE's terrain manager (in abstract). It lets you load multiple terrain blocks and have them be part of the same terrain, so that your effective terrain area is greater than the default 256x256. This involves significant changes to the terrain code - a whole rewrite, more or less. The rest of the engine code is (for the most part) untouched. Obviously, there'll be many small changes to places in the engine that interact with the terrain, but that's about it.
Just a note - for backwards compatibility, TSE will support loading TGE terrains. It's currently very easy to port a Torque game to TSE, and the terrain changes I'm working on won't change that... unless you've done a lot of terrain hacking. But if that's the case, you'll have a bunch of cleanly commented, cruft-free terrain code to work with, so it will be easy to recreate your changes. The same holds for our graphics changes - it's very easy to port code that was using TGE. If you made graphics changes, it'll be a little more difficult, since you'll have to recreate them, but you'll have the benefit of a nice, shiny graphics API to work with...
You can buy the TSE EA release if you own TGE for $150. So if you walk in and buy both you pay $250. The final price for TSE will be $295 - if you buy the EA your ownership will carry over.
Hope that clears things up.