SyntaxBomb - Indie Coders

Changed the files terrain.cpp, geosphere.cpp and isosurface.cpp to fix a bug, that caused the library not to work if no texture was applied.

Also, now I have a github repository:

https://github.com/angros47/OpenB3D

Hi Angros,

I added a few fixes for terrains a while ago, mainly alpha blending and texture shader both in UpdateTerrain see. I had to change TurnOn to take a terrain instead of the vertices vector. I renamed a lot of variables too so I hope you can follow it, I don't know if it works for GLES.

Also I fixed the heightmap data in CopyEntity which seems to use the wrong x and y values (ie. x is y, y is x) so the map doesn't orient correctly. There are also issues with the corners not being set and the whole edges on the right and bottom row. I still couldn't fix the bottom row though as it seems to always mirror the top row. Any idea about that? Thanks.

Likely because the raw height map data are stored as a linear array (each row of value is stored in sequence), and the rendering routine, when it arrives at the end of a row, reads the first value of the next one. That duplicates the last line

Corners, too, are not set correctly because they are the first vertices evaluated in the recursive subdivision. I was never too bothered by these issues, because a terrain is not supposed to be explored near the edges anyway: seeing a terrain abruptly ending (and maybe having the player's character falling out of the level) would kill the gaming experience even if no artifact were present.

Ok thank you Angros, but I still don't understand why the bottom row is exactly the same as the top row.

I was able to fix setting the top corners but obviously couldn't fix anything on the bottom row. Also when I say bottom, that would actually be the right edge in your terrain code.

The reason is because there is a technique of using multiple terrains for infinite terrains and fast rendering, if you use a huge terrain it will slowdown to much but if you use something similar to an octree of terrains then that solves the massive terrain problem, but in order for this to work the terrain edges need to be exactly what they are supposed to be.

I was talking to someone who has already written a system like this in Openb3d, I think it was Xaron, but he was using normal meshes. It looked very good though.

To explain what happens, imagine a block of text: it can be memorized as an array of bytes, where each bite is a character
Then, imagine to display it as line of 100 characters each: the first line will contain characters from 1 to 100, the second from 101 to 200, and so on, But if the first line goes from 0 to 100, the second from 100 to 200, the third from 200 to 300, what would happen? The character in the 100th byte will be displayed at the end of the first line, and at the beginning of the second. Hence, the right column and the left one will contain the same characters. I think something similar happened to terrains.

In the approach you described, I think that the "something similar to an octree of terrains" is actually called a quadtree. If you are going to use such an approach, the terrains can be actually simple meshes, there is no need to use the ROAM algorithm, since the quadtree can implement also the LOD. You would still have issues at the terrain edges, by the way, when matching terrains of different resolutions.

The quadtree approach is faster than the ROAM approach, but requires more memory, because the different levels of detail are computed in advance and stored in memory instead of being computed on the fly.

OK thanks for the complete answer, that makes sense.

What is the difference between a quadtree and an octree?

The difference is that in an octree each node can have up to 8 children, while in a quadtree it can cave at most 4 children.

Since a cube can be divided into 8 smaller cubes, while a square can be divided into 4 smaller squares, an octree is the ideal structure for recursive subdivision of 3d space, while a quadtree is ideal for a 2d plane (and for some special cases, like terrains). A quadtree is also often used for tile maps in 2d games.

OK thanks again, Angros.

If I understand correctly then perhaps a simple example would be a LOD terrain scenery but using meshes, with a quadtree you can have 4 LOD per scenery mesh but with an octree you can have 8 LOD per mesh. Is that right?

I don't think you would need any more than 4 LOD, so what would be a proper actual use for octree?

4 children, not 4 LOD. For each LOD you multiply the number of children by 4 in a quadtree, and by 8 in an octree

Let's assume a terrain with 3 LOD: at the lowest level we will have a single mesh, low res. At the second level we subdivide it in 4 meshes, each one with medium resolution, and at the third level we subdivide each one by 4 again, so we have 4*4=16 meshes. The total amount of meshes would be 1+4+16=21 meshes, that represent the terrain (or part of it) at different resolution.

In an octree, replace 4 by 8; so, 1 mesh at first level, 8 at the second, 64 at the third, 73 in total.

For a terrain, indeed, you don't need more than 4 children per node. But if you want to represent a cave, or a large building, you would need an octree with 8 children, so you can make LOD even for things that are above or below the observer

Right, yes I see. Thanks very much. No more questions.