Tiled terrain scene node

[arras]

Don't be sorry lug, I am thankfull that you waste your time with that. I replaced whole array with dinamic one and updated all dovnload links so you are wellcomed to try it.

I was developing makeRandomHills function in C++ environment without Irrlicht originaly. That's why I declader pi myself and later it was simply left there. No other reason for that.

[trooper]

AWSOME,

This has been long awaited by many people

I'm not near my own machine, but I'll be trying this out real soon

PS. What version of irrlicht is it ?

.

[arras]

thanks trooper,
it is made for Irrlicht v. 1.2

I still plan some improvements. Firsth of all I want to optimize it for better speed.

I am thinking about spliting visible terrain into sections and test if each section is on screen. This would exclude about 60-70% of tiles from rendering.

Another thing is that I want to include some kind of Level of detail.
And I have two possible aproaches in mind. Unfortunately both having some impact on texturing so it will be dificult.

One is classical one: tiles near camera will be divided in to more tiles. This would give more detail close.

Second which I like more would be to render parts of terrain which would require more detail with higher LOD of tiles (road in countryside for example) while uninteresting parts will be rendered with tiles with lower LOD (plain terrain for example).

There is EMT_SOLID_2_LAYER existing but only for DirectX. If it would work olso with OpenGL it would make texturing way easier ...unles it would have some catastrophic impact on speed. Lets hope it will be implemented for OpenGL soon.

[miko93]

AWSOME,

This has been long awaited by many people

...

I'd like to second that. Arras, keep up the good work

[Midnight]

demo crashes while loading.

and dev c++ sucks balls.

it seems to crash on the third loading thing I can't read.

gen terrain.. texture... crash.

[arras]

miko93 >> thanks

Midnight >> hmmm, I have no idea what might be wrong, third thing on loading is normals calculation, but from you wrote it seems that it is texturing which chrashed. Would you spare some time and try to recompile demo on your sistem? Sourcecode is at the begining of this post.

[HLFat]

I also experienced a crash in the Demo during the third loading phase.

So I built the Demo with my system,Digital Mars, and the crash happened in the call terrain->smoothNormals(), as you suspected.

I commented out the call, and it worked fine.Looks pretty good also.

I will follow up and try to figure out what is going on in smoothNormals();

I used the source code from your site.

Edit: Hang on,I tried it with Borland Turbo Explorer, and it worked fine.
No crash.Just had to reposition the camera a bit.So there is a problem with my Digital Mars.

Very nice work!

[arras]

thanks HLFat, newer the less this whole thing makes me worry. smoothNormals is part of class and it is strange that it crash on some sistems while runs smooth on others...

I will look at it when I will have bit more time and check if function is not reaching out of data array. But that would cause crash also on my sistem so I realy don't know.

thanks once more...

[Aardaerimus]

First off, I just have to say that this is simply fantastic and exactly what I've been looking for. Excellent work!

I'm both a complete Dev-C++ and an irrLicht newbie, yet I was able to compile just fine.

Now for my extremely "noobesque" questions: (please be gentle on me)

1.) I've created some seamless textures for tiling, but it would seem that no matter what I try it uses random segments of the texture thus creating seam lines all over the map. What are the recommended dimensions for a tile texture to create smooth and seamless tiling?

2.) I noticed that you prefer to use EDT_OPENGL, but when I change this to EDT_DIRECT3D9 my framerate nearly doubles. Is there a logical reason behind your selection of this video device such as a lack of features or display issues, or is it simply an avoidance of things Micosoft?

Just curious. Again, thank you for sharing this project! It's a dream come true and answers some big questions I had regarding the use of large maps and why my computer would lock up when I tried to use them.

[arras]

Welcome Aardaerimus to Irrlicht community

There is nothing wrong about your questions also, you are free to ask.

1. -texturing is done with two functions:
virtual void setTexture(char* filename) -which just set texture for whole terrain. If you just want to use simple texture on all tiles it is all you need to do (call this function).

virtual void setTileUVs(core::vector2d<s32> position, core::vector2df uv0, core::vector2df uv1, core::vector2df uv2, core::vector2df uv3) is function you have to use to set UV coordinates of individual tiles.
-position is position of tile you want to set UVs
-uv0 are UV coordinates of lower left corner of tile
-uv1 are UV coordinates of upper left corner of tile
-uv2 are UV coordinates of upper right corner of tile
-uv3 are UV coordinates of lower right corner of tile

note that origin of UV coordinate sistem is in upper left corner of texture UV space.

In order to be able to use 2 or more diferent textures you need to make tiles where two textures blend together and put them all in to one file. Look in to demo "Media/terrain.bmp" for example. "terrain.bmp" consist of 4x4=16 tiles of 256x256 individual textures. This is not easy way of texturing but it is standard way tiled terrains are textured.
As I wrote, once EMT_SOLID_2_LAYER material type will be available also for OpenGL I'll try to rewrite whole class to use it. That would make texturing way easier.

2- I use OpenGL simply because in order to use DirectX with DevC++ you need to recompile irrlicht.dll which I am lazy to do . No other reason for that.

If your problems with texture persist, feel free to ask here. Aslo posting part of code and screenshot might help sometimes.

[ElgarL]

I'm afraid I get a stack of errors when attempting to compile this under VS6.


Being both a newb to Irrlicht and VC I'm at a loss .

Code: Select all

d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(55) : error C2374: 'i' : redefinition; multiple initialization
        d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(45) : see declaration of 'i'
d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(59) : error C2374: 'j' : redefinition; multiple initialization
        d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(56) : see declaration of 'j'
d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(82) : error C2371: 'j' : redefinition; different basic types
        d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(56) : see declaration of 'j'
d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(102) : error C2374: 'j' : redefinition; multiple initialization
        d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(56) : see declaration of 'j'
d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(104) : error C2374: 'i' : redefinition; multiple initialization
        d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(45) : see declaration of 'i'
d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(108) : error C2371: 'j' : redefinition; different basic types
        d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\tlmeshbuffer.h(56) : see declaration of 'j'
d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\somefunctions.h(141) : error C2374: 'j' : redefinition; multiple initialization
        d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\somefunctions.h(96) : see declaration of 'j'
d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\somefunctions.h(209) : error C2374: 'i' : redefinition; multiple initialization
        d:\vb projects\irrlicht-1.2\examples\paging landscape\tltdemosource061228\somefunctions.h(93) : see declaration of 'i'
D:\VB Projects\irrlicht-1.2\examples\Paging Landscape\TlTdemoSource061228\main.cpp(45) : warning C4305: 'argument' : truncation from 'const double' to 'float'
D:\VB Projects\irrlicht-1.2\examples\Paging Landscape\TlTdemoSource061228\main.cpp(45) : warning C4305: 'argument' : truncation from 'const double' to 'float'
D:\VB Projects\irrlicht-1.2\examples\Paging Landscape\TlTdemoSource061228\main.cpp(45) : warning C4305: 'argument' : truncation from 'const double' to 'float'
D:\VB Projects\irrlicht-1.2\examples\Paging Landscape\TlTdemoSource061228\main.cpp(106) : warning C4305: 'initializing' : truncation from 'const double' to 'float'
D:\VB Projects\irrlicht-1.2\examples\Paging Landscape\TlTdemoSource061228\main.cpp(107) : warning C4305: 'initializing' : truncation from 'const double' to 'float'

[arras]

basicly these are two kind of errors:

second one (C4305) is not even error, it is only warning and should relate to passing irrlicht tipes like u16, u32, f32 to "swprintf()" function which require standart C types like int, float or double. I think you can overlookt them.

with firsth one (C2374) I have problem hovewer . Obviously it relate to use of i and j variables in for() function ...like:
for(u16 i=0; i<size; i++)
To be onest this is mistery to me since both definition and initialization are local to for() function and why your sistem take another for(u16 i=0; i<size; i++) as redefinition and redeclaration I realy don't know.

Hase somebody else idea what does this mean?

[HLFat]

I will look at it when I will have bit more time and check if function is not reaching out of data array. But that would cause crash also on my sistem so I realy don't know.

It took me awhile. but I think I figured out my problem.

Code: Select all

// recalculare normals of whole terrain making it smooth
    virtual void smoothNormals()
    {
        for(int j=0; j<size.Height; j++) {
            for(int i=0; i<size.Width; i++)
            calculateNormal(i, j);}
    }

In the smoothNormals function,a value of j=0 is being sent to the calculateNormal(i,j) function.That's fine when i=0,but as soon as i goes to 1, data[x][y-1].height is evaluated:

Code: Select all

// calculate vector to point 0,-1
        if(x>0) // check if not out of data array
            v0 = core::vector3df(0, data[x][y-1].height-data[x][y].height, -tileSize);

Since y is a u32, y-1 is 4294967295.

One compiler crashed at that point,another didn't care.

To fix the problem, I started j at 1 in the for loop of smoothNormals():

Code: Select all

virtual void smoothNormals()
    {
        for(int j=1; j<=size.Height; j++) {
            for(int i=0; i<size.Width; i++)
            calculateNormal(i, j);}
    }

[HLFat]

Hase somebody else idea what does this mean?

I don't know, but see if it helps to define i outside of the for loop:
Just define u16 i only once, and replace for(u16 i =0; ...)
with for(i =0; ...).

Code: Select all

        size = isize;
        position = core::vector2d<s32>(0,0);
        u16 i;
        
        // create array of tiles
        tile = new Tile*[size];
        for(i=0; i<size; i++) tile[i] = new Tile[size];
        
        Vertices.set_used(size * size * 4); // four vertices per tile
        Indices.set_used(size * size * 6);  // two triangles per tile three indices per triangle
        
        // asign vertices to tiles
        u16 n = 0;
        // vertex ID later used to fill indice array
        u16*** vertexID;
        vertexID = new u16**[size];
        for(i=0; i<size; i++) vertexID[i] = new u16*[size];

I think the redefinition comes from multiple references to u16 i in all of the different for loops.

[hybrid]

The redefinition problem is due to someone using old microsoft compilers. They did not implement the official scoping rules such that variables declared in for loops have a larger scope than just that loop. That's also why Irrlicht uses this 'outside scope' semantics which is quite annoying and ugly
The truncation is indeed not really bad, but also not due to Irrlicht's types which are simply typedefs, i.e. just other names for the underlying C types. The compiler won't see any difference to real C types.