Holes in terrain (irr 0.14)
Holes in terrain (irr 0.14)
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.
If I move just a little bit back and forth this hole, camera "falls" through
terrain.
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.
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.
totaly offtopic
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 ...)
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 ...)
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
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?
"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?
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
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
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.
(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.
YASS - Yet another Space Shooter
under Devolpment, see http://yass-engine.de
under Devolpment, see http://yass-engine.de