Game Development Community

Terrain size limitation

by Tom Punt · in Torque Game Engine · 11/02/2001 (3:03 pm) · 27 replies

Has anyone tackled the repeating 256x256 terrain size limitation yet or will I be the first to attempt increasing this fixed terrain size?

Torque Owner Tom Punt

About the author

Recent Threads

NextNext Thread

PrevPrevious Thread

More from Torque Game Engine

Page «Previous 1 2 Next»

Torque Owner Tim "Zear" Hammock

11/02/2001 (5:19 pm)

I tried to increase it to 512x512 (arbitrary size choice). I flopped. Mebbe. I never managed to create a terrain that size to test the loading...

Would love to see what you come up with. I've come to the conclusion I would rather be able to tile 4 256x256 tiles together in a square and surround that with an infinitely repeating tile. That make any sense?

Nevermind. I should just go home...

Torque Owner Bill Johnson

11/04/2001 (1:30 pm)

I'm working on extending the Torque engine to arbitrarily large worlds, and this is going to be the first thing I start hacking, I imagine. I'm going to try to subdivide the world into 256x256 blocks and allow the assignment of heightmaps to blocks in an arbitrary way. In THEORY, this shouldn't be too too difficult... but from my skimming of the engine it looks pretty daunting... can anyone tell me what I'm in for here? :)

Bill

Torque Owner Rick Overman

11/04/2001 (4:20 pm)

You are taking the correct approach. The earlier version of this terrain engine (Tribes1) took did exactly that. At a high level there really not that many differences between the two terrain systems.

--Rick

Torque Owner Alexander Porter

03/28/2002 (1:41 pm)

Is there a way to tell the computer to subdivide only the terrain squares that are larger that the average size. such as if i were to make a huge hole, it would work, but the textures would be super stretched i think. and also- does anyone know where i can change the height range from a black & white bitmap. although i dont think they are spported yet...... are they?

Torque Owner Sabrecyd

03/28/2002 (2:05 pm)

If you're talking about importing greyscale bmp files. You can set the min height and the max range in the terraformer. I know that works.

Even though it says Bitmap in the Operation section of the terraformer, I think only png files saved in the \common\editor\heightscripts\ folder path will work. That's what I use anyway.

Torque Owner Alexander Porter

03/29/2002 (12:31 pm)

i know how to import them to make a map, but i think it sometimes creates those large tiles, which are often stretched unequally and look hideous. does anyone know if we could write a function for the editor/terraformer to subdivide any tile if it was to large? an example would be that i am trying lets say to build a plateu in a dessert, the plateu walls will be 90 degrees and the top will be relatively flat. this has worked before to make that, but the cliff textures are all stretched out. is there a way to either cause textures to be tiled on a terrain tile if there is enough room for another repetition or is there a way to subdive that individual tile if it is too large and therefor make it look right???

-Alex

Torque Owner Bryan Turner

03/29/2002 (1:27 pm)

Alex,

The specific change you are mentioning (texturing a near-vertical surface) requires a fundamental change in the texturing of terrain.

While the current system uses a 'painted cloth' that is dropped over the terrain and tacked into place, what you're asking for is much more complex. It requires an arbitrary mapping between terrain coordinates and texture coordinates. This is basically how player models work.. a mapping between the 3D model vertices and the 2D texture map (ie: skinning).

--Bryan

Torque Owner Bryan Turner

03/29/2002 (9:21 pm)

I poked my head into the Terrain Rendering to see if I could glean any info for this thread..

Looks like there are two separate terrain rendering engines, but one of them is commented out. (both look complete, but the commented out one gives an assert on texture levels when I enable it)

The working one appears to do a lot of stuff with edges and textures. I don't understand this part much.

Most of the work is done by a function renderChunkOutline() which outputs the tri fans for the landscape into vertex buffers. While the actual GL work is done by renderBlock().

The abstraction layer looks pretty well defined:

TerrainFile - Appears to save/load height field data.

TerrainBlock - Encapsulates the height field and collision detection, calls TerrainRender.

TerrainRender - Encapsulates the rendering engine, which consists of tessellation in renderChunkOutline() and GL calls in renderBlock().

While on the surface this seems simple to extend (ie: just allocate multiple TerrainBlocks which match edges, then render them in series). I don't see an obvious mechanism to do this (may be hidden in the scene graph, I didn't look that far up).

The collision functions are another problem. Since I've not written a real collision engine yet, my experience is limited. It appears that the important routine here is castRayBlock(), which assumes that the start and end positions of the ray are contained in the block. This is enforced with a modulus operation effectively wrapping the ray infinitely within the block. Again, I don't see an obvious mechanism to chain blocks together.

------------
My guess as to how to approach larger terrains for Torque:

- Locate the system which creates the TerrainBlock, and adjust it to allow for an array of TerrainBlocks.
- Load each block from it's file, and add it to the scene graph.
- The blocks will be called for rendering by the scene graph. They should render just fine as long as the textures were attached properly in the terrain files. (May want to render front-to-back.)
- Modify the collision calls to allow rays to scan through adjacent TerrainBlocks.
- Modify the lighting to correctly shadow adjacent blocks.

-----------
UPDATE:

Looks like it may be a bit more difficult. The terrain is rendered as a single object in the scene graph and all the rendering functions, etc.. expect to only use one block for the terrain. No wonder people have been having trouble with it..

I would suggest adding an additional abstraction layer which takes the place of the TerrainBlock in the scene graph. This layer would manage the loading/unloading of TerrainBlocks/Files and call the rendering function(s). for them, as well as abstracting the ray casting across multiple TerrainBlocks. It might also consolidate the APIs for the terrain into one place, they're currently scattered over several files.
-------------

Some questions for the GG crew, or anyone who might know:
- Why is every fan 'clipped' to the far plane?

This is not just a simple culling.. it actually calculates the intersection point for these fans and generates a fan which walks along the far clip plane. I thought this was extremely expensive compared to letting the hardware perform the clip? Is this for compatibility?

- What is the purpose of renderChunkCommander()?

Looks like it is a degenerate case (ie: really high up and looking at the whole terrain). Is this for compatibility with lower-end machines?

- Why is the Haze effect a texture?

Can this be done with vertex coloring? I have not studied fog rendering, but it seems expensive to burn a texture pass on it. Would it be possible to do by solid-fill with haze color, then alpha blending the main texture over it? Which would be faster?

- LOTS of static textures...

I haven't made it through all this code yet, but it often renders > 70 static textures for the landscape. Isn't this expensive compared to keeping a smaller number of larger textures on tap? What is the impetus for this scheme? Appears to be LOD selection, but I was not aware of so many different textures being available...

--Bryan

Torque Owner Alexander Porter

03/31/2002 (12:09 am)

Can any GG Employees shed light on this task?

Torque Owner Alexander Porter

#10

03/31/2002 (3:40 pm)

*bump*

Torque Owner Jeff Tunnell

#11

03/31/2002 (7:00 pm)

Mark shed some light in an earlier post as it has been addressed several times. This is a project that the community needs to take on. We feel it is not essential to creating a great game as it can be designed around, so GG won't be doing it.

Jeff Tunnell GG

Torque Owner Alexander Porter

#12

03/31/2002 (7:33 pm)

oky doky
is that how ya spell it?

Torque Owner Bryan Turner

#13

03/31/2002 (7:54 pm)

Torque Owner Robin Degen

#14

09/17/2005 (1:46 pm)

I wanted to post a new thread, but this thread is accactly my question. Has anyone managed to create such a large terrain yet? I'm not th

Torque 3D Owner Jesse Liles

#15

09/17/2005 (2:37 pm)

You can "stretch" the terrain tiles, which are made up of 256 smaller squares, by changing the line squareSize = "8"; in your .mis file to a larger number. I recommend only using numbers like 2, 4, 8, 16, 32, 64 etc.

I've heard about and seen a problem with water getting 'holes' in it when the squareSize is changed
from 8; which can of course be avoided if you don't place waterblocks in your mission =). There is also the more obvious problem that if you cut a hole in the terrain to use for anything you might want underground, the hole will be as large as your squareSize; A solution being that you could create large interiors or DTS shapes to place around the edges of the holes to make them smaller.

Using more tiles sounds good, I'd love to see anything that allowed me a larger unique terrain area with the same detail as the current one.

Torque Owner Robin Degen

#16

09/17/2005 (2:44 pm)

Well this is great help aswell. Thanks a lot!! Getting the terrain at a higher quality can allways be done in later versions of my game (there's no rush to that), i just want to get it up and running.

Torque 3D Owner Billy L

#17

09/17/2005 (3:09 pm)

I use some terrains with squaresize 128 ,its not looking bad at all .
But i dont use water on them .

Torque Owner Robin Degen

#18

09/17/2005 (3:11 pm)

Using water in an mmorpg is kinda needed. But, i think if you dont use to much curved edges (like a straight shore line) you wont see the "water holes".

Associate Kyle Carter

#19

09/17/2005 (6:24 pm)

TSE has a much more powerful terrain solution called Atlas, which you might want to review. It supports arbitrarily large terrains.

Torque Owner Robin Degen

#20

09/18/2005 (3:06 am)

I have, but it's currently out of our budget i'm affraid. I spent most of it on torque en visual studio 6.

Page «Previous 1 2 Next»

Post a blog
Add a resource
Start a Thread