New Tiled Terrain Scene Node [works with Irr 1.5]

[hybrid]

Hehe, I also just bothered with the warnings as the app crashed under Linux (fresh compile of course). The setter functions should simply be changed to void return. There are also some case sensitivity problems under Linux: One headerfile should be included as TlT not TLT and the Media directory should be media (with all references renamed) because the font loader seems to use all lower-case (which is a bug in Irrlicht to be removed in the future).
But now everything works and it really amazing.
BTW: Didn't Spintz also have a Tiled Terrain Manager? What are the differences (besides maybe one's using VBOs).

[sio2]

I've solved the culling. I added my own IrrSpintz-compatible version of ShTlTerrainSceneNode::isSectorOnScreen() and it now appears to cull OK.

Now on to sorting out the indices issue so I can load the tiles into HW...

BTW Spintz has a Tiled Terrain Manager. You'll have to ask him the differences.

[gunnicom]

I tried to compile the demo, but i get following errors i dont know why. I am running irrlicht 1.3 under Linux.

maptest.o: In function `~Random':
/home/gunni/projekte/irrlicht-1.3/include/SColor.h:176: multiple definition of `key'
main.o:/home/gunni/projekte/irrlicht-1.3/include/SColor.h:176: first defined here
maptest.o:/home/gunni/projekte/maptest/src/MCamera.h:158: multiple definition of `mouse'
main.o:/home/gunni/projekte/irrlicht-1.3/include/irrString.h:245: first defined here

[arras]

Eigen >> please try this alternative file: http://www.spintz.com/arras/Files/ShTlT ... neNode.cpp I have comented these lines in constructor:
162 material.MaterialType = video::EMT_DETAIL_MAP;
185 Material[0].Textures[1] = CTexture;
186 Material[0].TextureWrap[1] = video::ETC_CLAMP_TO_EDGE;
That should remove second texture from rendering. I wonder if it would work for you.

etcaptor >> thanks. I have no idea why it blinks. I hope it is something with camera not node itself. If you have time, you may try to recompile it with some Irrlicht build camera like FPS one.

sio2 >> that isSectorOnScreen() thing can have something to do with classifyPlaneRelation().
If you look at code you see that

Code: Select all

nearRel = box.classifyPlaneRelation(near);
if(nearRel == core::ISREL3D_FRONT) return false;

Which mean that frustrum planes face out of frustrum. Try to change it to ISREL3D_BACK or ISREL3D_CLIPPED for all planes. Just a suggestion.

I dont see howe I could share index data between tiles since tiles did not share vertices. If they would share vertices I would lost per tile texture support. Which was reason I started bothering with my own terrain node back then.

hybrid >> thanks
I am using DevC++ which is quit forgiving regarding type casting, it tend to silently cast where it needs to be as I understand. I was already downloading Code Blocs but did not install it yet. You know, once you are use to something its hard to switch to something else. If some of you could provide cleaned version of TlTMesh.h, ShTlTerrainSceneNode.h and ShTlTerrainSceneNode.cpp which compile without complains under VS2005 I would be thankfull

By that TLT you mean #include"TLTMesh.h" in ShTlTerrainSceneNode.h probably ...its just mistyping, I did not notice it. DevC++ is absolutely happy with it

On the other hand I dont understand what do you mean with

errors about functions that don't return values

-sio
and

The setter functions should simply be changed to void return

-hybrid

As much as I know if function should return void means It actualy does not have to return anything. Well thats at last what I have learned from Bruce Eckel and his "Thinking in C++".

BTW: Didn't Spintz also have a Tiled Terrain Manager? What are the differences

Yes he have one. from what I have understant his tiled terrain consist from static tiles with LOD. But he can describe it better for sure.

gunnicom >> what compiler do you use?

[gunnicom]

I use gcc 4.1.2 within KDevelop. Its an Ubuntu Feisty. There are some more similar errors btw. I did not want the posting to long, but can post all errors if you need.
My other Testapps compile.

[arras]

Looks like some problems with my event receiver. Which is strange since all Irrlicht classes like SColor.h have its own namespaces. I dont see reason why mouse and key should collide with some Irrlicht classes.

Try to use your own camera and event receiver. Perhaps Irrlicht build in FPS camera...

both mouse and key are global ...but once again I dont understand why it should be problem...

[EDIT]
Please try out this alternate file: http://www.spintz.com/arras/Files/main.cpp It uses build in camera.

[gunnicom]

It was my fault ... my mainfile was maptest.cpp, but i left your file main.cpp in the project. So its clear that there is some double definition.Sorry for that dumb mistake.

Now there is only one warning, but i will get it fixed myself:

/home/gunni/projekte/maptest/src/MInput.h:28: Warnung: nicht lokale Variable »<anonymous struct> mouse« verwendet anonymen Typen

(Should be something like "local variable uses anonymouse type")

[Spintz]

sio2 >> that isSectorOnScreen() thing can have something to do with classifyPlaneRelation().
If you look at code you see that Code:
nearRel = box.classifyPlaneRelation(near);
if(nearRel == core::ISREL3D_FRONT) return false;
Which mean that frustrum planes face out of frustrum. Try to change it to ISREL3D_BACK or ISREL3D_CLIPPED for all planes. Just a suggestion.

I dont see howe I could share index data between tiles since tiles did not share vertices. If they would share vertices I would lost per tile texture support. Which was reason I started bothering with my own terrain node back then.

Yeah, I changed the frustum's in IRRspintz, but more so, the interpretation of which side of a plane is visible. I think Irrlicht has them backwards. IIRC, other engines/frustum examples I looked at, had them the way I do in IRRspintz, which is how I came to that conclusion. And to me, it makes sense that something in "FRONT" of the plane, should be visible, not something in "BACK" of it.

[Eigen]

If I comment these lines out, I get a plain gray heightmap. The detailmap is still not visible at all, even if I change the color of the image. It just doesn't show up. Perhaps you were compiling the demo with different compiler settings .. I really don't know. Because if it works in the demo, it HAS to work elsewhere too.

[arras]

Spintz >> I had some rough time with that plane relation untill I got that isSectorOnScreen() function returning correct value

Eigen >> thats very strange. If old terrain loads texture new one should too since afther comenting those lines both use the same material type.

Try to use this code:

Code: Select all

video::ITexture *txt = driver->getTexture("Media/dirt_x_43.bmp");
terrain->getMaterial(0).Textures[0] = txt;

instead of:

Code: Select all

terrain->setMaterialTexture(0, driver->getTexture("media/dirt_x_43.bmp"));

at line 223 in main.cpp

or perhaps:

Code: Select all

video::IImage* img = driver->createImageFromFile("Media/dirt_x_43.bmp");
video::ITexture* txt = driver->addTexture("texture", img);
terrain->getMaterial(0).Textures[0] = txt;

[hybrid]

By that TLT you mean #include"TLTMesh.h" in ShTlTerrainSceneNode.h probably ...its just mistyping, I did not notice it. DevC++ is absolutely happy with it

On the other hand I dont understand what do you mean with

errors about functions that don't return values

-sio
and

The setter functions should simply be changed to void return

-hybrid

The easy thing is not Dev-Cpp, but the case-insensitive Windows File System. For Windows and all Windoes apps, the files TlTMesh.h and TLTMesh.h are the same.
The problem with the setter functions is that you use the same signature as for the getter functions, i.e. f32 setSomething(f32 value). But you don't have a return statement (which is ok, except with this funtion signature). It's just a programming glitch, nothing bad.

[arras]

hybrid >> ah my goodnes, you men those functions in MCamera class. You are absolutly correct of course. Its misstake and I wonder why DevC++ did not complain.
Firsth I was looking at ShTlTerrainSceneNode class from up and down and could not figure out what are you speaking of. Then something lighted my mind and I looked in to other files

You may even ques howe I did it:
if you see something like f32 getSomething() and you need something like setTheSameThing its hard to resist and not copy/paste it and edit. And its easy to forget something on the way

Thanks...

[sio2]

I guess everything outside the frustum was being accepted (and hence not visible). Anyway, as I say, I took a few minutes and wrote my own version of isSectorOnScreen().

Re Indices: what I'm getting at is this - if, for example, you have a 3x3 array of tiles and each tile is a 256x256 terrain then you need only one array of indices for the nine array of vertices. If you split each terrain into, say, 4x4 sectors then you still only need one index array, just ordered so that individual sectors can be rendered - just offset into the index array for a specific sector; this index array can still be reused for each terrain.

I haven't examined your code forensically so I may be thinking of something slightly different to how you've got things set up. The above is ideally how you'd like to do things, though - an index buffer (array) for each terrain object is a waste.

[Eigen]

Code: Select all

video::ITexture *txt = driver->getTexture("Media/dirt_x_43.bmp");
terrain->getMaterial(0).Textures[0] = txt;

YES! Thanks, this works! Very nice. ^^

[sio2]

For Windows and all Windoes apps, the files TlTMesh.g and TLTMesh.h are the same.

Not even Windows is that lame!