New build of the TerrainManager and a plea for help

#1 I've just uploaded build 13. This version corrects the last known issues with terrain painting.

While I was looking into moving the heightmap data into the TerrainManager itself I discovered that the TerrainFile::buildGridMap was doing some initial alpha blending of the materials and was blending the values of the 0 blocks with the values of the 255 blocks.

#2 Does the Terrain Manager work with the CVS HEAD or the last full release (1.1.2)? Also, should I just copy the Terrain Manager files over the existing ones, or merge the code for the best, safest results?

Thanks

#3 I believe it works with the latest HEAD if this is the code I helped on about 2 weeks ago....

I would backup the files it wants to replace.. Extract the files, add the two terrain manager files into the project, and do a clean build...

If its not working at that point let me know and ill see what I can do on releasing a new version...

#4 Loonitik is right this is based off of the HEAD source as of about two weeks ago. I've not updated my source tree since then.

As long as you're fairly up to date on your source then the included instructions should work fine.

#5 Have you fixed the issue with terrain holes appearing on every block, and not just the one on which they were created ?

#6 Ken I haven't tested creating empty blocks yet I'll add that to my check list.

There were some serious issues with the orginal version and converting world coordinates to grid coordinates and the like which is part of the reason terrain painting never worked.

I'd say is possible, even probable that fixing the terrain painting also fixed the empty block creation.

#7 I just checked.. There's no repitition of the holes, but you can't set squares in non-primry blocks empty. Looks like I need to move updateGrid up to the TerrainManager like I did with updateGridMaterials. I'll make that a priority over the mission creation stuff I was going to start on.

#8 Awesome... Keep up the good work!

I hope we'll see this in HEAD sometime... If it's backwards compatible and doesn't involve a slowdown, it seems like it'd be a very logical step to take, once development has stabilized.

#9 I've been trying to get it to the point where it is 100% compatible. In fact, if it was only used to do single blocks of terrain you wouldn't notice that you were using it instead of the orginal terrain system. It's trying to get the extra terrain blocks to work like they're all the same blocks that's been the pain.

#10 I found the bug realting to empty squares. The terrain rendering code was set up to not render empty squares outside the first block. I've updated it to understand multiple blocks and it now works.

After I post this I'll package the code up and upload it. It'll be ready within an hour.

#11 Just wanted to thank you for the excellent work you've been putting into this code. I for one was dreading having to deal with this.

#12 You're quite welcome. I figured if *I* wanted this thing working others probably did too...

I've updated the source again. This latest build fixes material handeling so they're shared across the terrain blocks as well as enables the heightfield manipulation to work across mutliple blocks.

I'm sure there's still some issues remaining but other than multi terrain mission creation the known ones have been knocked out.

#13 I've found a few minor bugs that prevent compiling on Linux/GCC3. Nothing serious:

a) in terrain/terrManager.cc, around line 248
for ( S32 yi = yStart; yi < yEnd ; yi++ )

{

+ Point3F myPoint;
if (yi < 0) continue;

if ( yi >= m_nNumTerrBlocksHigh) break;

glPushMatrix();

myPoint = Point3F(xi*blockSize,yi*blockSize,0);
M TerrainRender::renderBlock( this, pBlock[blockIdx(xi,yi)], myPoint, state);

glPopMatrix();

}


GCC3 doesn't like the nested function calls at this location.


b) in terrain/terrData.cc, line 24
-#include "game/gameconnection.h"
+
#include "game/gameConnection.h"


Linux is case-sensitve. the lower-case "c" here results in a "file not found" error.

#14 grrr I'm usually pretty careful about the case thing, I spent a large block of time developing on various *nix platforms so I usually check those.

Since the last release the only thing I've done to terrain manager has been to reorganize things a bit to suppport inlining and const correctness to squeeze out a few cycles here and there (basicly all of the small pass through functions from the the manager to the terrain block and visa versa are being inlined)

#15 More bad news, I fear: While it compiles now, it crashes when I try to load a mission. It seems that the terrainmanager doesn't play nice with a lot of other resources. I suspect that Melv's fxFoliageReplicator is responsible for the crash (at least it crashes right after replicator setup). Have you tested this combination?

#16 It works fine with Melvs code. Chances are you're trying to load an "old" style mission, one that doesn't have a TerrainManager in it. I did manage to break backwards compatibility last build. Follow the enclosed directions for adding a TerrainManager to your mission file and it should work fine.

#17 I had a small question. Does this work with the day/night cycle code?

#18 Donavan - that was it. Now I can load my missions again.

But, here's another problem: It _does_ break Melv's fxFluid stuff. It seems that it treats everything as a shore, no matter how deep it really is and no matter how I set the shore depth (I've tried 0.2, 2, 20, 200 and 2000 - no change at all).

Also, I don't understand the terrain editor change. Say I have 4 heightfield .png files for my 2x2 terrain. How can I load a bitmap into a specific "terrain slot" ?

Finally, here's another bug - when I try to use the terrain texture editor, when I hit Apply the console says:
common/editor/EditorGui.cs (1960): Unknown command setTextureScript.
Object Terrain(1513) SimGroup -> SimSet -> SimObject

it's in the engine, I checked. I also did a clean build.

Sorry. I'm good at finding problems. :-(

#19 It gets better :-)

I've made another clean build, this time a debug instead of a release build. Now it bombs out as soon as I try to spawn:

GameConnection::joinTeam %vehicle:1 %variant:2
GameConnection::spawnPlayer
Spawn Position : -910.05 -343.507
Ground Level : 43.9181
Spawn Position Is Good
GameConnection::createPlayer
TurretB::onMount
WeaponImage::onActivate
Fatal: (terrain/terrCollision.cc @ 125) Never Tested: TerrainConvex::support()
Platform::debugBreak: triggering SIGSEGV for core dump

I've tracked this to this call in engine/collision/gjk.cc

void CollisionState::reset(const MatrixF& a2w, const MatrixF& b2w)
{
VectorF zero(0,0,0),sa,sb;
a2w.mulP(a->support(zero),&sa);
b2w.mulP(b->support(zero),&sb); // <-- this one
v = sa - sb;
dist = v.len();
}

This is where the fatal call is made.
My game is based on head, but we use vehicles, not characters (i.e. you spawn as a vehicle, like in the racing mod).
When I change my code so that I spawn considerably above the terrain, then it works until I touch the terrain, at which point it bails out as above.

#20 @Thomas: Yep works fine with daynight code. The patch doesn't quite apply cleanly but that's due to a few things being slightly out of place from what the patch expects. It's onyl one file and the ".rej" file is pretty clear on what you need to do to fix it.

@Falcon: I'll take a look at the fluid code, I hadn't noticed anyproblems but it's probably nothing more that a height check going to the primary block instead of the proper block.

I've not done any vechicle work but I'll see about putting one in and tracking it down.

As for the Texturescript stuff I need to examine that a bit more and figure out how and why it's used and get it implemented properly.