Terrain texture clipped?

[hokan]

Still observing tutorials and found something unusual - terrain textures slicing a bit by left side. No matter what size of texture, terrain scale factor, proportions between height-map and terrain texture sizes.

For example.



so if I change some border texture pixels locking/unlocking its buffer, it'll have no effect
Moreover if you notice terrain has fade green line on the other side, not good at all

[hokan]

Don't have much time to play around with engine again, forgive me if I look like necroposter, but:
If you will use terrain heightmaps size of 2^N + 1 (just like default terrain scene node patch size), for ex. 257x257, texture will fit hightmap nicely. Nonetheless those fade green line on the other side of terrain still appear (just tested on 1.8 linux version).
Note that heightmap size inside engine which you get via

Code: Select all

pTerrainSceneNode->getBoundingBox().MaxEdge.X / pTerrainSceneNode->getScale().X

for example, will have value like 2^N. But vertices array will have size 2^N + 1 x 2^N + 1.

And one not elegant tip how to get real (heightmap) count of vertices on each axis:

Code: Select all

 
scene::IMesh* pMesh = pTerrainSceneNode->getMesh();
u32 terrainVertciesCount = 0;
for (u32 i = 0; i < pMesh->getMeshBufferCount(); ++i) {
terrainVerticesCount += pMesh->getMeshBuffer(i)->getVertexCount();
/*
here you can also check what type of vertices you need by checking this value
pMesh->getMeshBuffer(i).getVertexType()
*/
}
u32 resultTerrainVerticesCountByAxis = core::squareroot(terrainVertciesCount);
 

obviously this works only for square terrains. Correct me if I wrong, but Irrlicht supports any proportions between terrain sides sizes?

[Seven]

I had the same texture issue and found my issue being related to the the LOD system.

[hokan]

You mean creating heightmaps with predefined 2^N + 1 -size on each side? But it's not flexible and usable for user, moreover it doesn't solve problem getting size of terrain via getXXX methods.
P.S
Find out that Irrlicht can operate only square heightmaps, selecting result side size as minimum of sides sizes of heightmap. So addition vertices count by iterating through every mesh buffer seems to be appropriate.