leopardpm wrote:since everything 3D these days is based on triangles, does a 3D primitive cube have its square faces converted to 2 triangles (inside the engine)?
In Irrlicht, typically that is what happens. I think Irrlicht allows for non-triangle polygons, but the graphics chip converts them to triangles in the end, anyway.
In Irrlicht, the typical method to create a mesh is to describe a list of points, or vertices (x,y,z), and then another list that gives sets of connected points (each set forming a polygon), or indices, along with a texture or color per point (on the first list).
leopardpm wrote:
Edit: in thinking about this, and thinking about the 'subterranean' spaces (caves), a cube face is only possibly visible if it is exposed to an 'open' or transparent cube, having a list of all possible visible cube faces, even if underground, then culling this list depending upon player position and intervening other cube faces, still seems a quicker way to prune down the objects needed to render by the engine, right? You probably are already doing this I figure though... my thinking is just trying to catch up to where you guys are (way above me).
its much faster to have all block ids already sorted into ranges
Chung,
Very interesting... question: in 'mixed' mode, how do you compute the terrain mesh from your voxel data - marching cubes algo or something else?
i have the surface height from the top cube's altitude , stored in an array surface(nmax,nmax) then i draw it , with a skip when i want to show a cube.
looks pretty good, chung.... can you use higher res textures on the terrain (cubes look fine) - the terrain looks alot stretched.... also, when computing the height for the character when on terrain (works on the cubes fine), you need to interpolate the ramps for a height offset or the character goes into the ramp until jumps up to the next level cube.
leopardpm wrote:even if you did not do it to increase performance, the question remains: Does it increase performance to have one larger object instead of multiple smaller objects which cover the same 'area'?
Always. With one cube, you are calculating 8 points and then rendering a texture over the area (and maybe some lighting depending how complex your setup is). For multiple cubes you are re-calculating everything for every single cube.
ok, then, my next question is more OpenGL related (engine related): I understand how a heightmap translates into vertices of a terrian map. But how does the renderer know to use which vertices to connect the triangles to?
What I mean is this:
]].....A.....B....C....
1]----x----x----x----
2]--------------------
3]--------------------
4]----x----x----x----
given a grid of vertices (A1,B1,C1,A4,B4,C4) - the 'x' are the vertices. Why would the engine naturally choose to make terrain between the Quad of A1,B1 & A4,B4 as the corner points instead of corners of A1,C1,A4,C4? Does the programmer specify the vertices of all the texture planes? Thinking about it, I guess he does, right huh?
OK, so assuming that is the case, then why not just translate the 3D array into a single mesh and when adding or subtracting a cube, just modify those parts of the mesh while leaving the rest alone instead of recalculating the whole mesh again?
for instance, expanding on my AWESOME grid diagram....
Assuming the Z coord is all the same, we have a flat terrain defined as a grid of cubes (there is a 'z' just cant see it right now...) which is 4 x 3.
Now, the player 'deletes' cube at position 2,2 (whose vertices are B4,C4 & B7,C7) so the program kills the mesh between those vertices, and adds 5 new surfaces (4 vertical, and one 'floor') using additional vertices of B4,C4,B7,C7 but on the Z-1 plane. do the reverse for adding a cube.
Wouldn't this method be lickity-split speedy and provide the renderer with basically one terrain texture instead of figuring out 1,000s (millions?) of 'cube faces' to cull and deal with?
Since it is one mesh, there would not be the possibility of 'floating' cubes unless defined an entirely separate object for each mass of cubes, but so what? Still would be faster.
This is basically what Chung is doing with his project(in a way), but his seems very slow - why is that?
Wait a second! Chung, are you saying you store an array of all the 'surface' cubes? Surface(x,y)?! And when you render the terrain, you iterate through all the cubes (or all the surface cubes?)... either way then THAT is why your routine is so slow! Why don't you do the morphing mesh idea in my post above?
Did I miss something? Is the terrain mesh data accessible to alter realtime? Forgive me if I am posing a stupid solution.
why store a surface array if i have all cubes yet ?
that is why i keep a surface data , updated at each cubes modification, which is drawn as a classical terrain.(gl_triangles_strip on insight terrain, 120 unit range for now), in mixed mode.
i calculate the surface when loading the terrain from file , and update it when a cube is added or removed.
the top cubes are then not drawn , instead a subrouyine draws the surface over the remaining cubes.
When loading up terrain cubes from file, you also calculate which cubes are the surface cubes.
Then when terrain is modified, you update your surface cubes list
when terrain is rendered, you send ALL the surface cubes
Do I understand correctly?
You haven't spoken about 'culling' the backfaces of the surface cubes or the surface cubes which are hidden behind other cubes - do you trim down your surface cube list to only those surfaces which can be seen?
If not, then this is why it is slow compared to gonzo's routine - he does some culling, where as you are sending every cube (and most likely every face!) to the renderer! I don't think that Irrlicht does hidden obj removal, or does it?
Your way is much easier, but slower. Gonzo is getting exponentially higher performance, dealing with millions of cubes compared to your thousands, I think.
Please correct me if I am wrong.
This is why I suggested making a mesh of only exposed cube faces at the time of loading from file (much like you already do for cubes), then directly modifying this mesh when terrain is altered/added. Even if you still neglect any culling, this method will probably double the speed (especially on flat ground as only 1 face is exposed vs sending all 6 faces!). Just a thought!
The culling is the real hard part of any of this, there is the 'Marching Cubes' method and probably some sort of modified raycast method (this would be my first choice, but it's hard and maybe too expensive)
the surface that i speek of is not a list of cubes.
it is an array of points (or mesh if you call it so) , one point instead of one cube.
anyway, it is in the source code...
