Not to slow your enthusiasm down, but to use ETM you will at some point have to link against it Though moving that point away from the library to the application is definitely a good idea.

As for vertices / indices: I'm not an expert, either, but it's really not that much of a mystery. You can imagine a vertex as just a point in space. It is basically a set of 3D coordinates stating its position. A vertex buffer is a collection or list of vertices.
Index buffers, on the other hand, state which vertices are to be used and how. An index is really just that - the index of a vertex in a vertex buffer. The index buffer doesn't care about the actual vertices, it doesn't even care about a concrete vertex buffer. They really only determine how a set of vertices is to be rendered. You can shape them into triangles. You can even omit certain vertices (that's what is done with terrain LOD - every second vertex from the previous level is skipped in the index buffer, creating coarser triangles, but still using the very same vertex buffers).

I'm hoping you can spot my nub mistake with tiling. I have made a function called setupTerrainCollisionObject which is meant to imitate the TerrainCollisionShape constructor. It allows for user defined number of x and z tiles used for collision parts. (must be power of 2)

I am using a Manual Object to verify that I am getting the vertices correctly. Setting z tiling seems to work fine (1/2/4/8), but when I specify x tiling for more than 1, I get line artifacts. Oddly enough, I am only plotting points, so lines should not be possible!

The break condition makes no sense (to me at least). Unless you changed the meaning of numTiles during the start of the function and the loop (which you should NOT do ), then both loops will only do one iteration each. You probably meant this:

Do NOT return on this. This is definitely an error from the calling code and should be answered with an exception. Some time someone (possibly you ) will call the function with invalid arguments and wonder why nothing happens.

Define variables as late as possible and initialise them in the process, if you can. If in this code you ever accidentally insert a line before OOData = ... which references OOData, you may or may not get a warning from your compiler, but you'll definitely get into trouble on runtime. Better change it to this:

Though generally a good idea, in this case setting OOData to zero is quite pointless because the variable goes out of scope immediately after that - there's no way anyone can access it after this line Unless you insert something there, but that will get you into trouble, either way.

For the loop, the break is intentional. Basically I am asking the user how to partition the terrain (how much x tiling and how much z tiling, which will tell me how many tiles to use to represent the terrain). The break is added only to stop after 1 iteration of a tile, so I can see the results. As you can see, I found a an issue creating a tile when more than 1 tiling in the x direction is requested.

Using mDepth and mWidth would iterate over the entire terrain, but I really want to iterate tile by tile.

x tiling = 1, z tiling = 1 (entire terrain is 1 tile)

|////|
|////|

x tiling = 1, z tiling =2 (terrain broken into 2 vertical tiles)

|////|

|\\\\|

x tiling = 2, z tiling = 1 (terrain broken into 2 horizontal tiles)

|// \\|
|// \\|

So I just get the vertices of the first tile and stop. The break would not normally be in the loop. Manual Objects are really a PITA for me.

I did not mean the break, and neither do I mind you to iterate over the tiles, but I still say the loop conditions are wrong

The way you are using startx and startz they need to point at the heightmap data position of the initial vertex in the current tile. That's why you are updating them with += (xTileSize-1), which is correct.

But, your tilesize may be 33 or whatever, wheres your numTilesX will only be 8 or something. Do you notice what happens when the loop runs? It will terminate after the first iteration, regardless of the break. You really need to use mWidth, mHeight, the step size of xTileSize ensures that you are only looping as often as you have tiles.

If you jump through the vertex array in tile-sized steps, and for each step run through all the vertices in the tile and add them to a renderable, you are doing what your previous code did (and what I do for the TSM).
The two outer loops jumps the width*height array in tile-sized steps.
The two innner loops runs through all vertices in a tile.

Yah, the functionality got lost between converting from TSM to ETM tiling, especially when I wanted to have a user specified tiling in x and z.

But I really don't like having embedded loops which alter variables used as the conditional for an outter loop. Not really sure if this will fix the line artifacts I was seeing, but the code looks cleaner in my eyes!

The loop variables were identical before KungFooMaster's last post which is definitely an error. Of course, you could omit the update on the outer loops, change the loop condition according to what I said earlier, and it should work as well, but that's borderline readable

I ran into the getHeightAt function, this is only useful when you have Ogre 3d world space coordinates right? We want to be using the at function?

getHeightAt works in the coordinate scaling that you've chosen for the TerrainInfo object via setExtents. You can scale that to whatever you want and therefore scale getHeightAt to whatever you want. But I'd agree, to calculate discrete vertex positions, using the actual heightmap data is probably more elegant.

As for the ManualObject, so far as I see, you are still only filling in vertices, no index buffers. I have no idea if that mode of operation is even legal since from my understanding, the index buffers determine how a set of vertices is supposed to be rendered. If it is not legal, you shouldn't worry about it. If it is legal, then it's obviously rendering garbage (you aren't using the OpenGL renderer, by chance?), but I'm still not certain whether it's your fault. In any case, if I were you, I'd remove the ManualObject now and see if it's working with Opcode.

It looks like it's working! (2 x 2 tiling, meaning 4 tiles, and 4 bounding boxes seen in the screenshot) I won't know until the next part, where I actual make the ninja into a collision object and try to walk along the terrain.

My use of Manual Object must not be correct. Next time I have to do this type of work I won't put so much importance on Manual Object, especially if I'm not using it correctly.

CABAListic, just thought I'd pop in and see if you've done anything recently with ETM? Have you found anything that you think needs work, or any core features that you want to add? (Is it likely we'll see v3?)

On another note, how goes progress on your own personal work? (revival of a strategy game or something similar)

I'm currently not missing any major features, and none have been suggested. I suppose further documentation and examples about material usage (especially dynamically created) may be helpful, but that'll have to wait. So the next release I make will be a maintenance release, including your getHeightmapData call, a Linux makefile and any bugfixes that I stumble upon (found one in the SplattingManager, for example).

As for our personal project, it's not going anywhere near as fast as I'd like it to, but that's due to University. I have the basics of the map editor and will hopefully be able to work on the game more in autumn

Ok, I've released a first maintenance update, v2.1. Changes in detail:

Fixed Linux compile errors and added a very basic Makefile. The CodeBlocks project file also has build targets for Linux now.

Corrected the ETPrerequisites.h header.

Fixed bug: SplattingManager::setNumTextures(0) (integer overflow)

Fixed bug: Loading brushes from images failed for some image formats

Added feature: You can now pass the SplattingManager a list of texture colours, which are then used to generate a colour map.

Added feature: createMinimap function which takes a colour map and a lightmap and modulates the two to produce an image that is suitable for a terrain minimap.

Added feature: TerrainInfo::getHeightmapData() call

The added minimap feature I felt necessary for my map editor, and since I think that someone else might also need it, I included it into the ETM library. Here's a quick example of what ETM is currently capable of doing (if you put enough effort to it):

(Although, to be fair, the terrain in this screenshot is automatically generated by libnoise and auto-textured based on height )

1000 per frame? Heh, hm, that'll be trouble anyway, I'd guess. ETM's rayIntersects is by no means optimised (although it should be a definite improvement over TSM), but I doubt you could get it up to that speed. Of course, it depends on how your ray queries actually look.
Opcode is a dedicated collision library, so it may be faster. But then, it does collision tests on triangle level, so it probably has its limits, too.