Terrain... to mesh or not to mesh??
Hi all,
Let me start with my target is: A 3d tiled terrain on the lines of Warcraft 3. The terrain will be mostly flat with only a few elevations or depressions. Also, the terrain itself will be static, ie. doesn''t interact with what''s on it.
The textures will be tiles including their transitions, so I will avoid blending from one texture to the other. Each quad will have its own texture/tile.
I do not need heightmaps or advanced LOD algorithms, because as I said above, the terrain is mostly static and does not require fine detail. The details will be in tiles.
Now, I''ve been exploring 2 possibilities:
1. Either create a grid of trianglestrips (using vertex & index buffers), or
2. A grid of meshes.
Furthermore, I suspect that both possibilities will need to have quadtrees and frustum culling implemented as I would want to draw just what''s visible... obviously.
I know that many many people around here have done 3d terrains or are currently doing so, so I would like to ask you guys what would be the best to implement regarding:
1. Rendering performance
2. Coding complexity
Thanks,
Ivan
If you use meshes in the same way we used to use graphic tilesets, all of your height variations (slopes, hills, etc.) will have to be pre-built. Plus, you''ll have a hard time making certain that everything lines up perfectly. You could also just use Max to create the levels completely, then break the terrain up into culling-optimised blocks. This would probably give you the greatest design flexibility -- max can do *everything* -- but optimisation in your engine will be problematic.
Using the tri strips (in a VB) allows you to overcome all of those limitations because you are basically building all the terrain features from a height-field (I don''t think you understand Height-Map''s correctly btw. I could be wrong). The down-side is that you have to use different code for terrain and terrain features (rocks, walls, etc.).
Personally, I find that using the strips with a vertex buffer is the best way to go. It gives you much greater control over the terrain with much greater ease. The biggest hurdle has been creating the map editor (8 months in and nearly warcraft III-perfect now!) and I could have saved a huge amount of time just doing everything in Max.
Using the tri strips (in a VB) allows you to overcome all of those limitations because you are basically building all the terrain features from a height-field (I don''t think you understand Height-Map''s correctly btw. I could be wrong). The down-side is that you have to use different code for terrain and terrain features (rocks, walls, etc.).
Personally, I find that using the strips with a vertex buffer is the best way to go. It gives you much greater control over the terrain with much greater ease. The biggest hurdle has been creating the map editor (8 months in and nearly warcraft III-perfect now!) and I could have saved a huge amount of time just doing everything in Max.
Sorry. Inadvertently hit send there.
To continue...
the coding complexity of creating a vb solution is not that much more difficult than using meshes(except for the damned editor!). You can create your strips on the fly using just a handful of very simple functions that read the height-field and assign the values to a vertex. In terms of creating the geometry there is little difference between this and loading meshes.
Your main render code would also be pretty much the exact same thing. You''d have a culling thing that would traverse a database to find out what elements are visible and then render them. The database would probably end up being a grid layout in both cases and the geometry render code for either would be no more than 20 lines (even with complex texture blends and the like).
In terms of performance, I reckon it would make very little difference depending on how you stored your database and geometry. A VB with 1,000 polygons will render the same speed as a mesh with 1,000 polygons (all other things being equal). Managing your render states and texture assignments might be slightly faster in VB''s than in Meshes, but not so you''d notice much.
I''d say that your biggest factor in doing all this is how much time you''re prepared to spend on creating the terrain editor. You can do a simple height-map generator in a week or two, or you could go the whole hog and build a fully-functional editor in a few months (brush sizes, cliff heights, function-based patch editors, copy & paste routines, interpreted group modification, blending-tile set algorythms, etc).
To continue...
the coding complexity of creating a vb solution is not that much more difficult than using meshes(except for the damned editor!). You can create your strips on the fly using just a handful of very simple functions that read the height-field and assign the values to a vertex. In terms of creating the geometry there is little difference between this and loading meshes.
Your main render code would also be pretty much the exact same thing. You''d have a culling thing that would traverse a database to find out what elements are visible and then render them. The database would probably end up being a grid layout in both cases and the geometry render code for either would be no more than 20 lines (even with complex texture blends and the like).
In terms of performance, I reckon it would make very little difference depending on how you stored your database and geometry. A VB with 1,000 polygons will render the same speed as a mesh with 1,000 polygons (all other things being equal). Managing your render states and texture assignments might be slightly faster in VB''s than in Meshes, but not so you''d notice much.
I''d say that your biggest factor in doing all this is how much time you''re prepared to spend on creating the terrain editor. You can do a simple height-map generator in a week or two, or you could go the whole hog and build a fully-functional editor in a few months (brush sizes, cliff heights, function-based patch editors, copy & paste routines, interpreted group modification, blending-tile set algorythms, etc).
To answer your first post, although using VB''s give you direct access to the vertices, you can also do so with the mesh by calling the GetVertexBuffer and then change the vertex that you want.
As you said, depending on what style I use, the terrain code will be completely different but at the end of the day will do the same thing.
I don''t want to create whole levels with max, but just create an empty mesh and then work from there. I thought of using meshes because if hides the code of creating vertex & index buffers and you can also optimize meshes. I could use heightmaps but for what? All starts from a perfectly flat terrain, so heightmaps will be redundant in my case.
I have all the time I want as this just for learning purposes and for having fun along the way.
Looks like you have done something similar to what I want to do. Do you have a link to your project??
Ivan
As you said, depending on what style I use, the terrain code will be completely different but at the end of the day will do the same thing.
I don''t want to create whole levels with max, but just create an empty mesh and then work from there. I thought of using meshes because if hides the code of creating vertex & index buffers and you can also optimize meshes. I could use heightmaps but for what? All starts from a perfectly flat terrain, so heightmaps will be redundant in my case.
I have all the time I want as this just for learning purposes and for having fun along the way.
Looks like you have done something similar to what I want to do. Do you have a link to your project??
Ivan
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement