Game Development Community

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
#21
04/15/2002 (4:49 am)
Bryan and Melv,

If you would like, I would be happy to help you with the documentation on this. E-mail me and send me what you've got, what you want to say, and I'll create a draft that you can review, and I'll revise it as you go along.

David
#22
04/17/2002 (5:51 am)
Melv,

No prob, I'm out of town till monday anyway..

David,

Docs!! Woot! There's some initial docs in the archive, but we really need some images that describe how the NxM matrix of terrains works and what it looks like in various configurations. If you can pop out a couple of pics with numbered squares in 1x1, 2x2, and 2x3 or 3x2 configurations, that would be a good start. (numbered right to left, top to bottom)

Lightmap update:

I now have lightmaps working across terrain boundaries correctly for an NxM repeating terrain. It's quite a resource hog though, since it builds the entire lightmap in one pass and no longer gets the benefit of shift operations for speedups. *sigh*

Build 3 will be posted next week with lightmap support.

--Bryan
#23
04/22/2002 (9:50 pm)
I posted Build 3 with Lightmap support (links have been placed at the top of this thread).

- Lightmap support for NxM matrix, shadows cast properly across terrains. MUCH SLOWER than original Torque code.
- David is working on some docs.
- Melv? Any luck on waterblocks?

Has anyone else built and verified this code on their machine?

Thanks!
--Bryan
#24
04/23/2002 (12:36 am)
Hi Bryan,

Unfortunately, I only got my PC up and running on Friday, software installed on Saturday, Booze Saturday night, hangover on Sunday!

I was going to do some shader work tonight but I will look at this instead. I'll let you know how I got on later on Wednesday.

All the best.

- Melv.
#25
04/23/2002 (1:46 am)
Good solid work there bryan, just wanted to chip in and say that! :))

Phil.
#26
04/24/2002 (11:53 am)
Bryan,

For some reason I'm getting a fatal assertion "Not a terrain, but a terrain type?" in "SceneGraph::addObjectToScene(SceneObject* obj)" when the TerrainManager is trying to add itself to the scene server-side.

The object appears to be valid. I'm using a clean build (specially setup for this) and have followed your instructions to the letter. My mission file appears to be in order as per your instructions also.

I'll have to investigate this further and see what I can dig up.

- Melv.
#27
04/25/2002 (12:06 pm)
Phil,

Thanks for the encouragement, it's nice to know people are interested in this. :)

Melv,

Interesting.. sounds like an error I was having with TerrainBlocks after I turned off their TerrainType attribute. Perhaps I missed a file in the archive? David, have you experienced this error? I know David reported some compile problems with the latest head, I hadn't merged the terrain code before releasing it.

I'll clone the HEAD and apply the archive to it as a test. Let me know if you get it resolved in the meantime. Probably Friday or Saturday.

Status:
- Fixing known bug with collisions at terrain boundaries (raycasting bug).

--Bryan
#28
04/25/2002 (12:22 pm)
I plan to look at this again later Bryan.

I'll certainly let you know if I find what the problem is.

All the best,

Melv.
#29
04/26/2002 (9:48 pm)
Melv,

Try Build 4. I merged with the head about 10 minutes before zipping up the archive. I also tested extracting it on top of a clean version of the head, it builds fine.

Build 4:
- Fixed collision on terrain boundary bug (raycasting). Not the 'correct' fix, but it works for now.

Up next:
- Get terrain editor working again.

--Bryan
#30
04/27/2002 (7:06 am)
Bryan,

I'm getting ready for a all-night GG session starting in about 3 hours (my girlfriend is going out on the town and staying out all night).

Your code is first up so I'll give it a try and post my results the evening.

Later.

Melv.
#31
05/02/2002 (10:40 am)
Update:

I have the editor working, and can modify both terrains at once (even using the tool across the terrain boundary). Have not tested texture painting or other advanced features yet.

Unfortunately this work has exposed a fundamental flaw with my TerrainManager hooks. It looks like I will need to revisit all the wrapping code inside the collision, rendering, square tree, etc.. to ensure the terrain edge samples are taken from the proper locations.

So far I've fixed the rendering and it works perfectly with a mild hit on performance (can be inlined to avoid the stack frame setup).

It will take some weeks to finish the collision and other code wrapping changes (yes.. *weeks*). After this work is done, the TerrainManager as I see it is also complete.

Hopefully this project will be useful to the Torque community as a whole. :)

--Bryan
#32
05/17/2002 (5:31 pm)
Done! Woot!

I present to you the complete and working TerrainManager class implementation. Yes, there are still bugs and issues, but it is now feature-complete.

Have at it! (see first post for link)
--Bryan
#33
05/18/2002 (12:44 am)
Awesome, Bryan! Thanks a bundle! :D
#34
05/18/2002 (3:41 am)
congrats, thanks for the effort.
Interesting watching the progress of this thread.
jolly good
#35
05/18/2002 (8:11 am)
Very nice Bryan!

Some questions:

1. In your zip was an engine directory with various subfolders with various files; are these files impacted by terrManager (why were they included in the zip?)?

2. Is the squareSize fixed at 8? Shouldn't this be variable; therefore a TerrainManager datablock setting?

3. Could you explain what the raycasting section is about? What's its purpose? And in particular, what is the bug you mention forcing only doing only the first half of the raycast?

4. In a comment in the setHeight section you say "Set the height on Both Sides of the terrain to be exactly equal. This is not correct, since the entire border of the terrain must be repeatable now..." What do you mean?

5. I have some flags added to the current terrain dataBlock that control the repetition and collision of repeating tiles:
repeatTiles = "0";
collisionOnTiles = "1";
Would/should these be added to the terrainManager? And could they then be used to turn on/off the terrain matrix repetition?

I'm very interested in this so I'm sure there will be more questions after I get it implemented. Thanks for your hard work.
#36
05/18/2002 (2:16 pm)
Desmond,

1) The files in the archive replace the files in Torque. I built the archive in this way to allow you to unzip it to the Torque directory and it would automatically replace the affected files.

2) squareSize is set to 8 at initialization. This was completely arbitrary.. I just never added the datablock interface to TerrainManager. I still use squareSize internally, so once the datablock interface is added it should all still work correctly.

3) RayCasting is how Torque does collision detection. When a ray crosses the border of two terrains, it has to be cut in half and run against each terrain separately. The bug is documented so it won't be forgotten. I rarely see this bug (rays are often very short), but there is a bug which sometimes causes the projectile to go through the terrain.

4) Hmm.. looks like an out-of-date comment, I've fixed all the wrapping problems with build 5. I'll change the comment, thanks.

5) It was never my intention to turn off terrain repetition. Rather, I wanted to build a terrain system which wouldn't 'hedge in' the designers. I believe the NxM matrix will fit the 80-20 rule and be sufficent for most of the Torque community projects.

If you add code which turns terrain repetition on/off for the TerrainManager, I'll be happy to add it to the project.

I look forward to answering more questions :)
--Bryan
#37
05/18/2002 (2:37 pm)
hmmm I think the 80-20 rule should be that terrain repetition should be settable :-) Most people (80%) would welcome that option, and only a few don't care (20%)... ;-)

In my experience the vast majority of the historic terrain discussion here has been about how to turn off repetition of terrain and waterblocks. As a matter of fact, I thought that was the intent of your changes, and that the multiple terrains features was something you just tossed in because you could. Of course, I know realize that was incorrect and backwards.

But now that I think about it, it doesn't matter all that much. As long as one isn't contemplating terrain floating in the sky or space (certainly a possibility), then one just needs to make a 'sea bottom' terrain that would be lower than the surrounding water level and of the right x/y dimensions, and include that as part of the NxM matrix in the right places.
#38
05/18/2002 (4:13 pm)
In Tribes 2 I made an island for a game. The mission area boundary had to have a water channel along it. It was annoying that the seductive islands in the distance were just repeats and that it was easy to get lost in channels outside the mission area.

For games for kids it needed to be simple with only one set of islands. Also when I make my local terrain in a game it is silly to keep seeing the same mountain when you fly onto the next repeat.

I don't understand the above discussion( so sorry if this is real dumb) but it would be nice if I knew where the button was that allowed me to have only one non-repeated terrain/seascape.

Thankyou for the terrific work on this area. It is great that there are enthusiasts on this topic.
#39
05/18/2002 (4:35 pm)
Brian :
Sorry to inform you.
But there is no button and at this time to get that you
would be forced to code it, there are some methods available if you search the forums.
#40
05/19/2002 (1:59 pm)
On the topic of 'islands' vs 'non-repeating':

I did not mean to imply that the islands were impossible with the TerrainManager, there is a large difference between 'no repetition' and an 'island'.

A 'no repeat' terrain is essentially sitting in the middle of a void, with no landscape around it. Falling off the edge of the terrain would drop you into the water and you'd sink forever... this is the feature I had never intended on adding.

An 'island' is a terrain surrounded by a repeating 'sea floor'. Note that this terrain still repeats! Just the 'middle' part does not.

I had originally planned to allow an NxM matrix be surrounded by another tile which repeats indefinitely, so that the NxM matrix is the 'island'. There are some technical problems with this plan though.. The lightmap would have to be generated twice, once for the NxM matrix surrounded by a border of seafloor, and once for a seafloor tile surrounded by other seafloor tiles. Otherwise you'd have 'ghost shadows', or lack-of-shadows in certain areas.

But, adding 'island' capability to the TerrianManager should be fairly simple if you ignore the lightmap problem.. By editing the TerrainManager to *not* wrap the X/Y coordinates, and instead call the seafloor block for everything outside of the NxM matrix.

The other area which is a bit tough with seafloor blocks is the terrain editor. If anyone has ideas how to solve these problems, I'm still interested in adding the feature to this project. It would bring the TerrainManager up to the 90-10 rule :)

--Bryan