Game Development Community

Help... T3D's terrain rendering (Black Line on Border)

by Andy Wright · in Torque 3D Professional · 12/05/2012 (7:54 am) · 8 replies

Okies, Ive been looking into the cause of the black lines on some parts of the terrain border's, Ive worked out what I believe is the cause, but im buggered if I can work out where to look in the code lol... blindly poked my way through the terrain rendering, generation and collision, but i cant find where it is trying to auto tile the terrain.


Basically the terrain is still picking up either some kinda of legacy code from when you could auto tile terrains. although it is not actually rendering how it is seaming up one edge of the terrain with the opposite edge, you will see along 2 sides of the terrain that there is an invisible strip of terrain squares that ties up to the height of the opposite side of the terrain. Most noticeable when you put the terrain editor brush to hang over the edge.

This causes the black like to get baked into the terrains shadow map.

If anyone has any idea how to approach/fix this, any help is appreciated.

To either not draw the edges of the lightmap which still wouldnt look right as you would have missing shadows in the places they are meant to be, or to stop it from wrapping the terrain on it's opposite sides like it is trying to seam itself up for auto tiling the way TGEA used to

a hack fix was to not render the first and last pixel around the edge from the heightmap, although that is impractical as collision is still there for the undrawn terrain, and its a bastard moving it all lower then the terrain you're latching onto as its invisible lol. Ideally, it would be to stop the terrain from from being created without the edges having ghost poly's that hook up to the opposite sides elevation.


(LOL at the captcha... fuk3d)
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Torque Owner smally
TBD
#1
01/12/2013 (4:39 am)
Andy this may be worth a shot, though I don't know how much or where the terrain skirts are used but worth a shot. I have yet to find a place where they are actually used outside of just creating them and rendering.

in terrain/terrCell.cpp, find the function TerrCell::createPrimBuffer
Look for the line
// Now add indices for the 'skirts'.
and comment from them to just above 
primBuffer->unlock();

inside of void TerrCell::_updateVertexBuffer
find 
// Add verts for 'skirts' around/beneath the edge verts of this cell.
and comment from there to just above 
AssertFatal( vbcounter == smVBSize, "bad" );

and then there is TerrCell::_updatePrimitiveBuffer()
find 
// Now add indices for the 'skirts'.
and comment from there till just above 
mPrimBuffer.unlock();


This will remove all the skirts from the terrain. I've done this locally on my own copy of the codebase, and have yet to see an unforseen side effect from it, but I'm only one person. Wider testing could be done, so I hope this helps you out. This fixed my issue with the black lines from the skirts of terrains on the 3 ati and 2 nvidia cards I've tested with. Hopefully this will fix your issue as well, now if someone can just fix the blending issue on the terrain this would all be really solid! :D

Torque 3D Owner Andy Wright
BrokeAss Games
#2
01/12/2013 (10:52 am)
I'll give it a go but i think thats what i did a few months back, which yes stopped the edge of the terrain from rendering, thus avoiding the black lines, but i think the collision is still there from where its trying to tile the terrain.

I'll give it another go to confirm though.

Torque Owner smally
TBD
#3
01/12/2013 (11:30 am)
Well, it's only removing the skirt though, not really the edge. I'll check on the collision.

Torque 3D Owner Andy Wright
BrokeAss Games
#4
01/12/2013 (11:33 am)
go to the starter plain desert terrain in the standard examples. find a part of the edge that has the black line on the border. drop your player there, and try to run off it. there is collision there, because it's wrapping up to the higher edge on the opposite side, thats where it gets the black shadow from on that edge. thats what i was tryiong to find in the code to disable, similar to the way i guess of disabling it from rendering the skirt/last pixel of the terrain, but it still creates the collision :/

Torque Owner smally
TBD
#5
01/12/2013 (11:48 am)
Hence why I said I'd check it :D Looking into it right now. This was something I also needed to be done, so.. two heads better than one.

Torque Owner smally
TBD
#6
01/12/2013 (2:59 pm)
ok Andy it's in terrData.cpp. The function is called TerrainBlock::getHeight( const Point2I &pos )

that is actualling calling getHeight from terrFile.h TerrainFile::getHeight( U32 x, U32 y ) const
and this function is wrapping the coordinates around

x %= mSize;
y %= mSize;
return mHeightMap[ x + ( y * mSize ) ];

Either change the terrData.cpp file to account for this before calling this function or just change this function to not wrap with a modulo operator.

Once you do that the terrain collision points will stop wrapping around to the higher values creating phantom walls.

We'll have to do the same thing to stop wrapping shadows and light wrapping around if they are as well, but this will stop the phantom walls.

Torque 3D Owner Andy Wright
BrokeAss Games
#7
01/12/2013 (3:00 pm)
oh you star, if this works, thats awesome.

Torque Owner smally
TBD
#8
01/12/2013 (3:03 pm)
Andy, just make sure to do something like 
if (x > mSize) x=mSize;
   if (y > mSize) y=mSize;

but try to be more accurate than that lol.. I did that locally and the collision creates a phantom wall, but it just drops off the edge, which I don't care about because if more terrain was on the other side of this terrain patch, it wouldn't do that.. still looking into removing the phantom polys themselves. Just running into time constraints.

I should note that there are a lot of functions in that file that %= to wrap around.

Fixing that will more than likely remove the world wrap from the terrain portion. Which to me is just fine.