terrainrendering: Last 16 pix of heighmap .. *RESOLVED*

[peterparker]

In terrainrendering of the 256x256 pix heightmap only 240x240 pix will render..
so even if the heightmap tiles perfectly, if you place two terrains next to each other, there will be gaps.
You can test this behaviour by placing a second terrain 256*<YourScaleFactor> in x or z direction: You will clearly see a gap. if you place second terrain on 240*<YourScaleFactor> both of them will touch.
Is this a bug, or is this by design?
[It is not related to V 0.14.0, but also to V 0.12.0]

Anyway it is a nice engine and fun to work with!

Peter

[sRc]

you need to add one more pixel (i.e. 257x257) to get it to render 256x256... it's done that for a while, it is necessary but I dont remember why right offhand (havent experimented with it since i found the textures and heightmaps load mirrored)

[peterparker]

Hi Anaconda!
The sample in V0.14.0 has 256x256 dimension. If I resize it to 257x257 the rendering shows a lot of errors[move near to a low place of the terrainsurface and look up, as the normals of the wrong triangles are facing down], also, if you count the patches in wireframemode, you can see that there are only 16x15 but I think there should be 16x16 as the heightmap has same width and height.

I have the errors in all renderers..

Greetings Peter

[sRc]

try drawing a single pixel point in each corner of the 256x256 heightmap in the example (its dark in those areas with the one in the example so for example all while dot there) so that each corner is clearly visible against the terrain (popping way out), you'll see what I mean

I do see the error with 257x257 tho... thats new it didnt do that before (in 0.11 and 0.12). but in any case the terrain node is such that in order to get it to be n size (n being a power of 2) the heightmap has to be n+1

[peterparker]

Hi Anaconda!
I drew the pixels as you told. It is a very good idea, because I do not need to count the patches So on 256x256 there is only the (0/0)-vertex drawn. The 3 othere edges are not visible. In 257x257 there are two points drawn: (0/0) and (0/1).
And to make it totally awesome:
In 129x129 everything looks correct: 4 edges sticking up into the sky.
Why does it work on 129, but not on 257

Any idea?

[lantis]

257 don't work becuse here again bugs in Irrlight , engine can't render heighmaps > 256 in 0.14 version

[hybrid]

257 don't work becuse here again bugs in Irrlight , engine can't render heighmaps > 256 in 0.14 version

I did not find any restriction in the changes, so why do you assume a general problem there? There are some problems with terrain rendering, indeed, but why should they be related just to heightmap size?

[Spintz]

257 don't work becuse here again bugs in Irrlight , engine can't render heighmaps > 256 in 0.14 version

Why are you even using Irrlicht then? All you can do is provide criticism and stupid questions! This comment is completely useless and provides no insight into the problem, or even results of some tests you ran, output to the console, etc.

How about providing the parameters passed to the addTerrainNode function. Are you loading a RAW heightmap or a BMP.

[lantis]

Spintz , as im say in another topic - try make BMP 513x513 and replace terrain-heightmap.bmp in Irrlicht 0.14 'mdeia' dir.
You can see broken terrain.


>Why are you even using Irrlicht then?
Already begin move my project to Nebula Device IrrBug usable only for projects like Tetris

[Guest]

@lantis:
So please do not waste your and our time/bandwidth/memory with your comments. I think with your attitude you will have difficulties in every community. But everybody should have a chance to learn.
Farewell, lantis
May be the code with you!

@spintz:
I just debugged into (your?) terrain code: the indexes are calculated correctly, but it seems that the indexlist is only 16 bit numbers, so that indeces > 65536 will be "wrapped" into lower numbers.
Unfortunately, a 257x257 heightmap has more than 65536 tris[exactly 66049]
Could that be the error?

Greetings,
Peter

[Spintz]

Spintz , as im say in another topic - try make BMP 513x513 and replace terrain-heightmap.bmp in Irrlicht 0.14 'mdeia' dir.
You can see broken terrain.


>Why are you even using Irrlicht then?
Already begin move my project to Nebula Device IrrBug usable only for projects like Tetris

What pisses me off about this, is the TerrainNode was and is implemented in my own time, by me, not by Niko, he just takes the changes and updates. What pisses me off even more, is that as Peter here suggested( and is correct ), Irrlicht only supports 16 bit indices, so the terrain gets all beyond repair and results are unknown. And then, what pisses me off more, is that it's not a bug with Irrlicht, or with the Terrain, it's just an implementation problem, the fact that no 32 bit indices are being used. However, with a little bit of searching( I know your incapabale of that lantis, you're too dumb ) you would find the patch that applies the code from IrrSpintz that makes the engine use 32 bit indices and you could have 32 bit indices in Irrlicht and your problem would be solved.

Thanks for pointing that out Peter, I was looking into that last night, but my brain must be fried, cause I was just looking at the number of indices, not what the values were.

Knowing this is the problem, I'm going to look into a way to switch between indices for different Meshes, etc. So you can use 16 bit indices for smaller models and 32 bit indices for larger models.

[peterparker]

@spintz @nico:
is there a reason for using 16bit indeces? I think in times of DirectX9, P4 and GBytes of ram some empty 16 bits are not important?
I am not very firm with AGP, fast performance rendering, modern GPU workload, so my question is:
is this 16 bit limit important for performance/memoryfootprint?
Or is it just a principle of economical coding practice(which is also a good thing)?
thanks for an answer!

Greetings,
Peter

[Spintz]

IrrSpintz uses 32 bit indices for everything, and I've not noticed any performance problems with it. If vertex and index buffers are used( which they are in DirectX when the device is created with the flag, D3DCREATE_HARDWARE_VERTEXPROCESSING, which is the default in Irrlicht. In OpenGL, VBO's are not used, and so the performance is slow.

My next step in Irrlicht, is to get VBO's working. I have some basic modifications to MeshBuffers and Meshes that will allow for vertexBuffers, and have it implemented in DirectX. Will take me some time to figure it out for OpenGL.

[peterparker]

i just replaced all "u16* indexList" arguments with s32* indexList and changed the other dependencies. I can say, there are a lot of changes, but they are easy[just replace u16 with u32] and after a recompile everything works fine. All bugs are gone. Even other features as BSP, animatedMesh and shadowvolume are working. I only tested Software, Software2 and OpenGL, but I think DX should also be no problem.
So if someone needs bigger terrains, just made this changes which will take you not 2 hrs and you will be fine.

Greetings,
Peter

[Eternl Knight]

Well, I for one am pleased as punch for your contributions, Spintz. It's good to see that the problem is solved and easy enough to see why you might have missed it (I use IrrSpintz too and as such, didn't have the problem!).

For the VBO's - are you talking about dynamic or static versions? Static one's are relatively simple to create but dynamic ones, I'm not so sure about. Not to say they aren't possible or even easy - I simply have never had a need to use them.

--EK