The "Big Terrain" Solution never explored..

#1 One way would be in you *.mis file. Change "SquareSize" to something larger. This also stretches the terrain tiles, though, so it won't look quite as nice.

#2 There are a lot of little constants to play with. :)

#3 @Eric: The SquareSize is what I referred to as "terrain scale" in my original message. Sorry if I was too vague. 16 to 32 meters per terrain square is ideal for the scale of our game.

@Ben: In going through the \engine\editor and \engine\terrain directories, as well as the \fps\common\editor\ directory, a search for "256" found (excluding terrain texture size references in blender.h and commented lines) 35 occurances. I restricted my search to those directories because from my understanding the terrain manager is fairly self contained.

Now of course not all of those occurances will necessarily relate directly to the terrain size, but: A) does this at least encompass all of the necessary places that the terrain bitmap size is referenced, and B) is this all there REALLY is to it?

#4 All the changes you will need to make are in terrain\. However, there are a lot of exciting little relationships between the constnats to find out about. So just changing the 256s, while a start may not be the whole solution.

#5 Thanks for the info... Seems its worth a look afterall.

#6 If you are trying to make the world about double the size of the current terrain tile there are a couple of things you can do which - in concert - may get you there...

I have looked at this issue repeatedly and recently had a good reason to go back and look it over seriously again.

I have what might be a couple useful suggestions for you.

I initially tried boosting the size of the terrain. However it very quickly becomes obvious that there will be some serious issues with the appearance. If tile size is raised above 10 the sides of mountains and water become increasingly jagged. It is not noticible at 10, noticible to a critical eye at 12. By 16 the effect is very noticible.

There is an alternate solution which also has some merit. That is to reduce the scale of the models. I have taken the model scale down as far as .25 .25 .25 and found that collision and other factors seem to work pretty well. (I tried .1 .1 .1 scale initially but the character can literally run through the walls if he picks up a little speed.

So you can combine the two to get a pretty good single large terrain - or even several large tiles using the terrain manager. Set the terrain tile size up to 10 from 8 and reduce the size of the characters and buildings by scaling them down to (.5 .5 .5)

You will have to adjust a couple of other items - character speed when running and the distance the camera is behind the character when in third person mode. Below (.5 .5 .5) you may also see a problem with long weapons in hand going thru the earth when you look down in first person mode, but all these should be relatively minor fixes that can even be done through the scripting language.

Hope this helps out a bit.

#7 I think Gorpe has almost solved this problem. I managed to load 12 different terrain blocks altogether in my machine successfully using Gorpe. :-)

#8 I will confirm what David Dougher has said above about scaleing down your models size and also increaseing tje tiles size. While detail is NOT a major issues for my game since it is a Pirates Style Combat game where 99% of the game is controling a ship out in the ocean.

Since terrain detail was not a issue for me I went with a terrain tile size of 14 and a character size of .5 .5 .5

But keep in mind most of what any player will see in my game is rolling ocean and highly detailed ships (5k+ polys). Most of the land in the game is very unimportant except for the ports that the ships pull into to purchase cargo, upgrades, new ships, ect.

#9 Has anyone considered trying to implement something akin to "scrolling" across a larger image?

What I mean is, think of the 256x256 heightfield as a window onto a much larger image, and the point at which the player is as the center(always). Then, as the player moves, thus moving the center, the heightfield is updated with the new "view" of the larger image, and that is translated into a theoretically large scale terrain model. I think I might play around with that a bit to see what I can come up with(aside from lot's of crashing, lol).

Of course, what I haven't thought of is how to deal with all the objects in the game, and how their positions will be computed, though I think a good place to start thinking about that solution is maybe phasing the models in and out as the enter/exit the scope of the map.

Just an idea =)

#10 That's a pretty slick idea, but the implementation within Torque's terrain rendering framework could be really hairy. It does a quadtree implementation with a lot of optimization, so if you "scrolled" the data you'd have to regenerate all the intermediate data.

I have no idea how much of a hit the regeneration would be. You could swap the quadtrees in/out of memory, too - that might work a bit better, but then you'd be back to tiling like GORPE does. Hmm.

#11 Yeah, I know very little about quadtrees, though I got the idea from the terrain plugin I'm working on for trueSpace/gameSpace. I have a 400x400 working area, and I can load the 3300x2560 heightfield for my game and scroll through it, changing the heightfield "view". It looks cool too ;)

I'm probably going to get a clean version of HEAD and beat the idea up a bit, to see how far I can get. Though, I haven't done any heavy TGE stuff yet, and I'm strapped for time because of my project, so it'll be a while(I need to get to alpha...).

#12 :(

www.garagegames.com/mg/forums/result.thread.php?qt=16052

#13 Turn that frown upside-down ;)

Have you checked the top of this thread? Possibly changing some of the hard-coded values in conjunction with the scale might help your situation...

#14 My problem is: currently I can have a large non-repeating terrain, but I don't really like the repeating textures. What I want is a single big satellite image mapping the whole terrain block.

I've been reading the terrRender and blender classes for one whole day... feel like lots of the parameters in blender are hard-coded, aren't they? I'm not really experienced in programming, and havn't figured out how to start my job. :-(

If someone has any idea about how could I achieve my goal easily, please let me know! Thanks!

#15 Seems only need to modify the Blender class...

#16 Done! I've mapped a 256 * 256 satellite image onto the whole terrain block. :-)

#17 Congratulations! How does it look?

#18 And share how you did it :)

#19 Hi everyone. We are a team of students at Melbourne University in Australia. We have been assigned a project which is basically the same as what Architecture@UOA has done above. We need to be able to use a large satellite image as the surface of a terrain. Does anyone have any suggestions on where to start? We have been analysing the code in the terrain folder but we're finding it very hard to understand. Are there any good explanations of the contents of the files in the terrain directory?

#20 Should be able to take the picture of the sat image and do a greyscale on it.. then save a bmp? and then import into torque.. torque will then read the various shades and create the terrain.. one thing tho if the transitions are sharp you will have jagged edges so try doing a blur on the image before importing so it blends better :)