Holes in terrain (irr 0.14)

[baramonto]

When I move across terrain, sometimes hole appears nearby camera.
If I move just a little bit back and forth this hole, camera "falls" through
terrain.

[Spintz]

You need to provide more information. Like screenshots, the heightmap you're using, etc.

[baramonto]

http://img208.imageshack.us/my.php?image=image14vn.png

note: hole appeared in middle of terrain

[Warchief]

Uhm, every post about terrain problem gets me to think that some code from Spintz went to niko's 0.14. That kind of problem is what i get with Spintz's 0.12.

[Spintz]

Can you email me the heightmap please

[Spintz]

I just took the heightmap used with the Terrain example that comes with Irrlicht, resized it to 257x257 and saved it as a .png file and loaded it, and it had problems. It's most likely a problem with the PNG loader, as the same image works when loaded from a .bmp file.

What image format ar e you using for your heightmap? Try saving it as a .bmp and loading it and see if it fixes the problem.

[baramonto]

I'm using terrain-heightmap.bmp from media directory

[baramonto]

Well, I tried to run code also in Irrlicht 0.11 and 0.12 but problem
remains the same.

[pr3t3nd3r_guest]

meybe some aliens came and steal some poligons because they don't have enought for an game they are working on

What is with that 256->257 and 512->513? The height map is procesed directly readed and applied ...(i don't realy belive that)? or stored first (means that is resized to 256 or 512) and used after ... (meaning that the original size is used virtualy ... some software strech ...)

[Spintz]

Are you asking why the terrain heightmaps need to be 257x257 instead of 256x256?

If so, search, if not, I have no idea what you just said.

[hybrid]

I think what was meant is that if the heightmap is stored as a texure it might be rescaled to a power of two and that way introduce some holes if later on used with original size. But the text seems to be chemically influenced

[Spintz]

Oh...the heightmap is read into an IImage, not an ITexture, only textures are stretched to a power of 2, not images.

[Pr3t3nd3r]

i searched:
"why AND the AND terrain AND height maps AND need AND to AND be AND 257x257 "

found

http://irrlicht.sourceforge.net/phpBB2/ ... x257#39871

Xeus32



Joined: 22 Mar 2005
Posts: 11
>Your heightmap should be 257x257. The heightmaps used with the terrain node >should be square and in the dimensions of 2^N+1 ( i.e. 17x17, 33x33, 65x65, >129x129, 257x257, 513x513, etc. )

Why the image in terrain example ( terrain-heighmap.bmp ) is 256 x 256 pixel?
If i use the size of 129, 257 i not obtain 9560!!!
129 * 40 = 5160
257 * 40 = 10240
513 * 40 = 20520
How you can justified that!

TNX
Xeus32

I don't understand what you're trying to ask here.

Spintz



Joined: 04 Nov 2004
Posts: 844
Location: Orlando, FL

searching "terrain AND heightmaps AND 257x257 " .. found the same
http://irrlicht.sourceforge.net/phpBB2/ ... x257#39871

searching "terrain AND heightmaps"
53 matches
... after 500 years of searching don't found the answer
(funny stuf) I know spintz have explained somewhere because i already read the post long time ago ..
... + in this 500 years i read somehere that spintz have made the terrain code cool

searching in: CTerrainSceneNode.cpp
... after 30 sec
... it could be an problem in calculateNormals()

and why
if (x>0 && z>0) ...
if (x>0 && z<TerrainData.Size-1)
if (x<TerrainData.Size-1 && z<TerrainData.Size-1)
if (x<TerrainData.Size-1 && z>0)

if x,y = 50;
and terain.data.size = 257
that wodn't do first if, second if, third if and the last if? calculating the normal 4 times ... hmm maybe this is the corect way ...
... maybe is something whrong with:
if ( count != 0 )
{
normal /= (f32)count;
normal.normalize ( );
}
else
{
normal = core::vector3df ( 0.0f, 1.0f, 0.0f );
}
//meybe should be core::vector3df ( 0.0f, 0.0f, 1.0f ); or oter stuf ...


ps.
Even if the textures get resized i don't think they should create holes ...
ps1.
Meybe the code can be rewritten to use 2^n/2^n height maps
ps2.
If we spleet an 1025/1025 in 4 (hmm meybe 1028 ). And create 4 terrain scene node's (hope is possble). Can we position then so that we can go from one terrain scene node to an other. (are them continuous?)
ps3. (some kind of portals or stuf .... and after that we just add the objects as a child of terrain node..)
If all those 4 'operations' are necesary for calculating the normals shouldn't the vertex from map margin use the 2 (1) vertex values what can be calculated?

[Spintz]

ok, where to start,

first off, the calculateNormals had no bugs, and I've actually replaced the custom code with a call to SceneManager->getMeshManipulator()->recalculateNormals.

second off, the problem with holes was mainly with DirectX. The DirectX device creation by default sets the FPU to single-precision round-to-nearest mode. This causes the FPU calculations for collision, which need to be precise, have problems. The other issues were posted about in Bug Reports forum well over a month ago, maybe 2.

As far as the search goes, I entered "terrain AND heightmap AND size" and on the first page found this post, with the answer - http://irrlicht.sourceforge.net/phpBB2/ ... 2269#52269

[MasterD]

To come back to the topic, I have the same problem:
(heightmap: bmp, 129^2)




The second picture is made after rotating the cam just a bit.

Could this be a problem of culling large amounts of terrain to early?
Since it seems to me, that it is like culling one half of the terrain.

Like
------
|V|V|
--P---
|C|C|
------
where v=visible; C=culled; P="player" watching nearly complete north
To illustrate what I mean.