New Tiled Terrain Scene Node [works with Irr 1.5]

[arras]

I have finaly finished new version of my Tiled Terrain Scene Node along with new demo. I call it Shifting Tiled Terrain Scene Node now. I was basicaly recoding it from scratch so there may appear some problems some of you were reporting with old one. Please be patient with me, this terrain have a lot of new features. Report back any bugs or problems you encounter. Of course some fresh ideas of howe to make it better are wellcomed too.

So whats new in comparison with old one?
Good news is that its MUCH MUCH fasther than old one. While old demo run at around 100 fps with OpenGl on my machine, this new baby gets at about 600 at about equal condidions.

Basic principle remains the same. Most important changes are that now mesh is split in to sectors. Depending on size there may be up to 25 sectors. Each is individualy culled and updated to save time. And it seems to pay of.

Another new thing is way it handle texture. I use S3DVertex2TCoords instead of old S3DVertex and EMT_DETAIL_MAP. Node creates one texture internaly, which I call color texture. This texture is stretch over whole mesh and gets updated from data array on run time. It basicly allow to set color for individual tiles. One pixel for one tile.
This color texture is blended in to another texture which acts as detail texture and have to be loaded from file by user. This detail texture can be manipulated the same way old terrain node manipulated texture. You can set its UV coordinates the way you want. You may build it from seweral diferent textures and then apply each individualy over tiles.

Resulting efect is that terrain keeps nice detail look close by plus gets some variability over distance.

[Bad thing is that there is some bug in Irrlicht which prevents me to use detail texture the standart way EMT_DETAIL_MAP material should work. I had to set detail texture as firsth texture and color texture as second. Ist not the best but at last it works.
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=20709]
-seems to be solved.

Also I have spend quit lot of time polishing getIntersectionWithLine function which is now much fasther than the old version.

And last I added new functions which give possibility to load data from height maps and color maps.

Downloads (thanks a lot Spintz for offering me hosting of files ):

Demo [ 2.3 Mb ] http://www.spintz.com/arras/Files/ShTlT ... 042008.zip
Source files for Irrlicht 1.4 http://www.spintz.com/arras/Files/ShTlT ... 052009.zip

Please look inside ShTlTerrainSceneNode.h for more detailed description about ShTlTerrain node.

[Update 07.04.2008]

Updated for Irrlicht 1.4. New demo, screenshot and sources uploaded. Demo runs only under OpenGl. I did not have patience to compile Irrlicht.dll with DX support with C::B and I did not find working one quickly.

Bug I was reporting seems to be solved and I changed texture order to proper one so textures should be rendered bit better. I was not testing it extensively however so please report here if you have some problems under OpenGL.

I did change most of u32s to s32s to get rid of compiler warnings quickly.

Use terrain->getMaterial(0).FogEnable = true to enable fog. Setting material flag does not seems to work.
Also use terrain->getMaterial(0).setTexture(1, driver->getTexture("texture")) since setMaterialTexture also does not seems to work for reason unknown to me.
I do not know what cause this. I recommend to use material directly to set properties if you encounter some problems.


[Update 17.04.2008]
Corrected memory leak in array2d which was reintroduced by last update.

getMaterialCount() made constant. This solves problem with setting material attributes and texture via ISceneNode interface in Irrlicht 1.4.

[Update 29.05.2009]
Found bug in array2d again by Darktib. Corrected. Was reported to work with Irrlicht 1.5. I was not trying myself.

[monkeycracks]

That's amazing Arras, I just wish there was an editor for it so I can use it in my project

I'd code one myself but I don't know how I'd go about saving/loading it.

[Spintz]

Looks sweet. Check your PMs.

[arras]

monkeycracks >> Thanks . Data terrain is build from are basicly height, normal, color and UV coordinates, plus some general variables like size. All are easily accessed so you may write / read them from simple txt file, XML or even texture.

Spintz >> Thanks for that file hosting offer

[sio2]

I get approx 600fps with OpenGL/Window and approx 770fps with Direct3D. The terrain is random every time so I did a few runs and picked the mean.

From a quick peek I see that you're using a 5x5 PVS of tiles (Potentially Visible Set) and just frustum culling them? Seems like a very good method.

I've gotta try this in IrrSpintz and see what loading the tiles to HW does to framerate.

[Eigen]

Thanks! This is really nice. I have a lot of use of this. But I'm having a little problem .. for some reason the detail texture doesn't show up. I used the source from the demo. The demo itself works fine with detail texture and all. I wonder what could be the problem..

edit: I compiled the demo source as well and it doens't work either.

[arras]

sio2 >>

From a quick peek I see that you're using a 5x5 PVS of tiles (Potentially Visible Set) and just frustum culling them?

Exactly. Actualy it depend on terrain size, 5x5 is maximum.
If I would cull each tile individualy it would take lot of time, to group tiles in to sectors results in good relation between culling precision and speed. As you can see on demo, out of 25 sectors around 9-11 is rendered. Thats mean more than 60% of polygoons are not rendered.

Also I have noticed that relation between number of polygoons rendered with one meshbuffer and performance is not linear. I have found out that if I render single mesh buffer with n polyboons its gona be slower than rendering 4 buffers with total of same number of polygoons if number of polygoons is large enought.

So single fact of spliting terrain mesh in to seweral meshbuffers mean quit huge boost to speed. Without actualy culling them.

I dont have idea why however, it have to have something to do with Irrlicht itself. I found it out by pure accident.

Eigen >> is there some console output like x.y texture could not be loaded or some other error mesage?

Also, in source files zip file, all media are excluded so you need to copy them from demo itself, keeping corect local path.

[Eigen]

No it says that the texture was loaded successfully. That's what makes it weird...

[arras]

are you using Irrlicht.dll which is included in demo or your own one?

Also you may try to use some custom textures instead of one from demo... It must be something simple since there is nothing special about thate texture and way it is handled by node. It is just loaded and attached to material as texture[0].

[BlindSide]

Wow this looks great and runs fast even on my MX440, only gripe is the resolution of the colour key, I know that keeping it like this keeps framerates up, and it doesnt look too bad when you look near, but if you look far or hover the camera too high you can see the square-ness of the individual pixels. Is there a way to try setting the colour key to a single colour or a higher resolution image? I looked around in the media folder but I couldnt find it so I guessed its embedded in the code somehow (Sorry if you already mentioned this.)

Another thing I am intrigued about is your camera, it is able to look down a full 180 degrees and flip back around, how did you achieve this? ie. Code your own FPS camera? Is this as simple as grabbing mouse input and setting the rotation as such or was it difficult? Also why did you use this camera instead of the ordinary FPS camera?

Oh yeah... Bravo Arras

[dawasw]

Outstanding.

[arras]

BlindSide >> thanks

Color key texture is hard coded in to node and you can control it with video::SColor getColor(u32 w, u32 h) and setColor(u32 w, u32 h, video::SColor newcolor) functions. Or you can use loadColorMap(const c8 *filename, u32 w = 0, u32 h = 0)
to load it from texture.

Resolution is one pixel per one tile. Not that it cant be more detailed but texture gets updated from data array with all lock/unlock stuff so it is partly performance issue, partly in order that user dont have to handle two diferent sizes/coordinate sistems: one for terrain tiles/vertices and another diferent for texture.
You can edit height, normal, color and UV of terrain using the same common coordinates.

Another thing I am intrigued about is your camera, it is able to look down a full 180 degrees and flip back around, how did you achieve this? ie. Code your own FPS camera?

Yes thats what I did. I dont like Irrilicht build in cameras since I like to have camera separated from control input. If you are interested just look at MCamera.h its quit simple.

dawasw >> thanks.

[Eigen]

Arras, I tried with other textures and I've tried different version of the dll, still nothinh. Could anyone else try to compile the demo's source and see how it works? I'm out of ideas here. Until then I'm reverting to the previous version of you terrain system, although it's a lot slower.

[etcaptor]

Arras i have not tried old terrain node, but this looks great!
Good FPS!!!
Only with DirectX got sometime blinking screen for some camera angles.

[sio2]

I've compiled with IrrSpintz and have it working. Strangely, no tiles are rendered as they're all rejected in ShTlTerrainSceneNode::isSectorOnScreen(). If I add a trivial frustum-box test I can cull and it works just fine, but the full plane-rejection isn't working in IrrSpintz for whatever reason. I'll take it over to the IrrSpintz forum.

VS2005 sure complains about a lot of stuff. There's a ton of signed/unsigned warnings (u32/s32 mixings), errors about functions that don't return values, and other bits-and-pieces I had to alter to get VS2005 to compile.

I can't compare performance until I get the frustum culling sorted and one other thing. Indices are passed as an IndexBuffer in the Spintz draw call and I'm building them from your index data. Do you share index data between tiles? If they're all the same size then you only need one set of index data and not one for each tile. Am I right?