Working on Terrain Manager class...

#161 @BT: It's not really THAT difficult it just takes enough familiarity with TGE and TerrainManager to understand what's a TerrainManager change and what's not. Even though I spent a lot of time in TerrainManager I only dealt with the portions that were incomplete or had bugs, so some of this is new to me as well. It's just time consuming, boring work but it's nearly done.

@BH: Think of TM as a terrain engine abstraction layer. Anything that dealt with blocks of terrain, including the renderer now goes through TerrainManager instead, for the most part. Implementing the same interface as TerrainManager would ensure that everything else works automagicly. Mucking with terrain in Torque is a major undertaking with ripple effects across the engine. TerrainManager reduces these ripple effects.

#162 Hi :)

For my (unannounched) project, I'm going to need well detailed terrain/maps of non repeating terrain blocks covering perhaps 200+ miles square (including real world topography ~ DEM)

I'd think MMPOG/RPG developers would need massive worlds as well ...

So .. is this where TerrainManager is headed in functionality or able to accomplish yet ?

I've got this 5 year old Dynamix game with dts/dml (plus .ted eccentially acting as a terrain mesh .dts file) files does massive arenas, Red Baron II/3D :)

sure seems like we could find a way to have Torque handle larger areas than what I've seen indicated .. or I'm missing some info somewhere ?

#163 That's exactly where TM is headed. My preferred zone size is 1024x1024 but then I also play some tricks and ring that area with additional terrain blocks so it looks like you can enter them. They're glorified imposters but since they are actual terrain blocks from the adjacent zones the zones always stay in sync.

#164 It seems to work with the lastest version of Torque.

#165 O.K
Dumb question time, what can one use on the winblows side to patch latest TGE HEAD with this nifty spiffy code?

-Ron

#166 patch.exe, comes with wincvs 1.2 ... or you can get it from unxutils.sourceforge.net/, which I would recommend, since it comes with lots of other keen tools.

#167 I downloaded the TGE HEAD today (may 13, 2003) and I am trying to patch it with the files I obtained from GORPE. I am not having much success. I've never used this patch.exe tool before so I am not clear on the syntax. Here's what I am doing, as per the instructions:

1. Copied terrManager.cc and .hh to torque\engine\terrain
2. At the command line, typed:

patch -d d:\divideddominion\torque -i d:\divideddominion\resources\temp\terrainmanager\terrainmanager.patch -p0

But it seems to be skipping over all the files. Here's is 'some' output:

|RCS file: /usr/local/cvs/gorpe/torque/engine/game/fx/lightning.cc,v
|retrieving revision 1.1.1.1
|diff -u -r1.1.1.1 lightning.cc
|--- game/fx/lightning.cc 1 Mar 2003 15:28:15 -0000 1.1.1.1
|+++ game/fx/lightning.cc 18 Mar 2003 22:14:58 -0000
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
can't find file to patch at input line 1848
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: game/vehicles/hoverVehicle.cc
|===================================================================
|RCS file: /usr/local/cvs/gorpe/torque/engine/game/vehicles/hoverVehicle.cc,v
|retrieving revision 1.1.1.1
|diff -u -r1.1.1.1 hoverVehicle.cc
|--- game/vehicles/hoverVehicle.cc 1 Mar 2003 15:28:15 -0000 1.1.1.1
|+++ game/vehicles/hoverVehicle.cc 18 Mar 2003 22:14:58 -0000
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
can't find file to patch at input line 1875
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:

I'd really like to get involved with this. But I can't get the patch patching. Any comment or suggestions would be greatly appreciated...

Robert

#168 you need to execute that command from the 'engine' directory.

Look at this part here:

|--- game/vehicles/hoverVehicle.cc 1 Mar 2003 15:28:15 -0000 1.1.1.1
|+++ game/vehicles/hoverVehicle.cc 18 Mar 2003 22:14:58 -0000

That shows you it expects to find that exact path ... game is a subdir of engine, so execute your command from the engine subdir, and it should work for you.

#169 JEREMY: thanks for the quick and accurate response. It patched and I am rebuilding the solution. It didn't build, which is something I was prepared for. When I look at the errors, it appears as though there are missing lines of code as there are variable used and not defined, wierd curly braces with no for loop, or preceeding condition.

The errors are:

\DividedDominion\torque\engine\editor\terraformer.cc(379) : error C2065: 'terrBlock' : undeclared identifier
\DividedDominion\torque\engine\editor\terraformer.cc(379) : error C2227: left of '->getHeightAddress' must point to class/struct/union
\DividedDominion\torque\engine\editor\terraformer.cc(384) : error C2227: left of '->buildGridMap' must point to class/struct/union
\DividedDominion\torque\engine\editor\terraformer.cc(385) : error C2227: left of '->relight' must point to class/struct/union
\DividedDominion\torque\engine\editor\terraformer.cc(1393) : error C2509: 'onAdd' : member function not declared in 'Terraformer'
../engine\editor\terraformer.h(61) : see declaration of 'Terraformer'

The suspected code is here:

//------------------------------------------------------------------------------
bool Terraformer::setTerrain(U32 r)
{
Heightfield *src = getRegister(r);

TerrainManager *terrManager = TerrainManager::getTerrainManager( false );
if (!terrManager)
return false;

F32 omin, omax;
getMinMax(r, &omin, &omax);

F32 scale = worldHeight/(omax-omin);
S32 sz = terrManager->mMetaBlockSize;

Point2F shift(mShift);
shift *= (float)terrManager->mMetaBlockSize / (terrManager->mMetaBlockSize * terrManager->getSquareSize() );

S32 y;
for (y=sz; y>=0; y--)
{
S32 x;
for (x=0; x<=sz; x++)
{
F32 f = (src->val(wrap((S32)(x+shift.x)),wrap((S32)(y+shift.y))) - omin) * scale + worldBaseHeight;
*(terrBlock->getHeightAddress(x,y)) = floatToFixed( f );
}
}
{
Point3F a(0.5, 0.5, -0.5);
terrBlock->buildGridMap();
terrBlock->relight(ColorF(0.8,0.8,0.8), ColorF(0.35,0.35,0.35), a);
}

Point3F pos = getCameraPosition();
pos.z = 0.0f;
setCameraPosition(pos);

return (true);
}

Just before { Point3F a(0.5, . . . there's something missing.

And of course:

bool Terraformer::onAdd()
{
if(!Parent::onAdd())
return(false);

TerrainManager *terrManager = TerrainManager::getTerrainManager( false );
if( terrManager )
{
setTerrainInfo(terrManager->mMetaBlockSize , 8.0f, 100.f, 300.0f, 0.0f);
noise.setSize();
}
return true;
}

This function is just missing it's prototype in the header.

I can add the prototype for onAdd. I have looked through the patch files manually, but I'm not clear on how to proceed with the previous function. I have either made a small mistake, or the patch missed a couple of small details. Thanks in advance.

Robert

#170 Never mind, i fixed the small patch problems, and it's building. I just had to look at it closer. Sorry for the confusion. the only problem I have now is that I get link errors in map2dif which I hope to figure out shortly.

#171 You know I just LOVE coming into a TM thread and finding that the problem has already been solved before I even have to open my mouth. Glad it's workign for you. Make sure to nab the bump mapping patch for TM too it's Chris did some spiffy work.

#172 Yes I will check that out J. Thanks a lot.

Robert

#173 An unhappy piece of news I would like somebody to confirm.

I have been using the Terrain Manager for a while (quite successfully), but I recently tried to see just how far I can push the manager and the system. I created a single flat tile with one default texture and tested it by repeating it for two squares - no problem. I then bumped it up to 4 squares - no problem. Finally to twenty squares - no problem. However somewhere between 20 and 23 squares the system fails with a C00005 error.

My initial though was - Ah-ha! You have run out of memory! So I tripled the memory in my system (It was a good excuse... ;) No difference. So, before I attempt to debug it I was hoping I could get someone else to confirm that they cannot get above 25 tiles... That way I can determine if it is a mistake I have in my implementation - or a general error to report back to the group.

#174 As I mentioned on GORPE.com. I've hit that wall myself, but I've not looked into it as of yet. I'll try and take a crack at it this weekend or so.

#175 There's some nasty things going on with what appears to be integer overflows and the like. Plus some things really need to be rethought when your start getting really big like water blocks, lightmaps etc. In a nutshell I'm not sure if TM will ever scale up very far.

At any rate it's late and I have to be up early to write yet more boring robot code for my day job. I'll think on this the next few days and see if i can come up with something haflway elegant.

#176 Out of curiosity, when you say you bumped it up to 20 squares, what exactly do you mean? 20 terrain blocks in one direction end to end? If so, what is your experience with 16 blocks 4 x 4? And how far in kilometers is that if it works reliably?

#177 The 20 suqares referred to 20 total squares. I assume arranged in a 5x5 grid. I know 4x4 works very well, and load pretty quick since that's what I've been using in my test zone. I had specced out 6x6 in my design however, so it's frustrating seeing that as the breaking point (since terrrain must be square the next step up from 20 blocks is 36).

If I recall each block is 2km square..

#178 Is it a problem to have let's say 6 Terrains? In a 3x2 grid? I think, i've read somewhere, that it won't work... But it has, at the beginning of TerrainManager at least...

#179 5x5 grid is 25 squares.

#180 Terrain manager allows you to specify the "pattern" of the grid. So you could have say, 5 wide x 4 high for 20 tiles, or 4 wide and 5 high for the same number.

(So, I assume in your post above Donavan, that your specific implementation required a 6x6 square, not that you thought the overall terrain pattern must be square as some people might be led to believe by your post.)

I originally started with 3x3 grid for 9 tiles, bumped it to 4x4 for 16. When I hit 5x5 it failed immediately. So I tried rearranging to 1x10 then 2x10 (both ok.) Next I moved to 1x20 (also ok) then began adding one block at a time (1x21, 1x22, etc.) Depending on which version of my software I was using it always failed on either 1x22 or 1x23. The consistency of the failure originally led me to suspect that it was a memory issue and that it was on a boundary (so one version could cram in 22 tiles while another version could manage 23). However, since adding more memory to the system completely dashed my hopes on that score, my next move was to see whether the failure was just me or others. Unfortunately, based on these posts, I see I'm not alone...

So that's the facts, no matter what "pattern" of loading you use somewhere between tile 22 and tile 23 bad things will happen to your implementation.

Oh, and just for the record,I tried this in dedicated mode too. I tend to be somewhat thorough about this sort of thing...