Advanced Terrain Textures
-
Joeff
-
Knobs
Yes you are right, the generated texture is 4096x4096. Like I said, I now want to render each patch with its own texture (which are 1024x1024 or something like that), the terrain from the pictures is the current terrain scene node of irrlicht.Joeff wrote:
great terrain! i worked on a texture-generator also, dont look that good but was ok, perhaps i can help you bit. and how you create a big texture when the map is 256 only? the texture dont look like 256
If there are enough people interested, why not?. I also try to code in "irrlicht"-style, so maybe its accepted as a contrib some dayvery nice pics, do you plan to release the source?
(I have to see how this works with "patched" terrains).I also saw a friend class defines called CTiledTerrainManager, but I couldnt find that in the irrlicht source. What is that exactly and is it still somewhere in the source? Since you can only load 256 heightmaps, it could be usefull to have some kind of manager which splits larger terrains..
The tiled terrain node manager is in IrrSpintz, and has been since version 0.12 of irrlicht. I guess Niko didn't take it when he updated the terrain node for irr0.14. It's easily added to Irrlicht, just have to modify ISceneManager.h, CSceneManager.h and CSceneManager.cpp and add the CTiledTerrainSceneNodeManager.h and .cpp.
Spintz, I am trying to do a 3D strategy game where I need a map that is made up from a set of small tiles (32x32???) representing the terrain type. I don't however, want the tiles to look too obvious i.e. I want the terrain to look fairly realistic. The map needs to be fairly large, ~1000x1000 tiles at the largest I would guess. What are my options for doing this?
The way I have been looking at doing this is to at the start, generate large patches e.g. 25x25 tiles (bigger???) where I do some smarts to blur/hide the edges of the tiles. These patches would have height maps and textures and I intended to use your TiledTerrainSceneNodeManager to display them. Do you think this is realistic? Is there are better approach that you can think of?
The way I have been looking at doing this is to at the start, generate large patches e.g. 25x25 tiles (bigger???) where I do some smarts to blur/hide the edges of the tiles. These patches would have height maps and textures and I intended to use your TiledTerrainSceneNodeManager to display them. Do you think this is realistic? Is there are better approach that you can think of?
MindGames, I think we are trying to do the same thing (I also started another thread for that). I thought a little bit about that and I think the way to do that is not to use the current 'tiles'. Because, a tile is in fact just a subdivision of your terrain and is used to reduce the level of details (thus the number of vertices that are displayed) for distant tiles.
In my case (and probably yours), one 'tile' (not the same tile as before, I know it is a little bit confusing) is probably made only of 4 vertices. And so, you cannot reduce the number of vertices that will be displayed because the different tiles use different textures also.
But, as discussed in my other thread (look here: http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=11610), a solution could be to have each tile render itself with a call to drawIndexedTriangleList (so, it is able to render its own texture). But of course, if you have a lot of tiles to render at once, that will be horribly slow. One major advantage will be that you can only pass to the driver a limit amount of vertices to be drawn: only those from the visible tiles. So, I don't really see how we can reduce the vertices to be drawn, but if your camera is above the terrain, the portion of it that will be displayed is really limited.
Spintz, could you maybe elaborate your answer ? I don't see clearly how we coud do that (sorry, I don't have a lot of experience in 3D).
In my case (and probably yours), one 'tile' (not the same tile as before, I know it is a little bit confusing) is probably made only of 4 vertices. And so, you cannot reduce the number of vertices that will be displayed because the different tiles use different textures also.
But, as discussed in my other thread (look here: http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=11610), a solution could be to have each tile render itself with a call to drawIndexedTriangleList (so, it is able to render its own texture). But of course, if you have a lot of tiles to render at once, that will be horribly slow. One major advantage will be that you can only pass to the driver a limit amount of vertices to be drawn: only those from the visible tiles. So, I don't really see how we can reduce the vertices to be drawn, but if your camera is above the terrain, the portion of it that will be displayed is really limited.
Spintz, could you maybe elaborate your answer ? I don't see clearly how we coud do that (sorry, I don't have a lot of experience in 3D).
-
Guest
Ced666
Yes you are right it is confusing as too many of the terms are being used for more than one purpose. I use the term 'tile' to refer to my small terrain type tiles and patches to refer the much larger Spintz style tiles. I hope that distinction makes things clearer.
I need to have a map that can easily be generated, with discrete terrain types (for path finding, movement inhibiting, visibility rules etc) and that looks reasonably nice. To achieve this, I have a set of terrain types (which are associated with their graphics tile) and the underlying map is a map of these types plus a height map. Due to the size of the map that I want, it is unrealistic (I assume - I have not actually run tests of any kind) to try and display all at once so I need some form of LOD. As I want to hide the edges between tiles I figure that I need to do some kind of preprocessing to the map before display (I dont imagine that I can achieve any kind of decent performance by doing it on the fly). I think there is a difference between what you are doing and I am doing in that as I intend using the underlying map to control positioning, movement etc I do not care if not every tile is shown completely accurately or not. So long as I can calculate the model's position for display purposes, I am happy. If in my preprocessing stage I produce a heightmap and medium size image to put on it, then the LOD effects can do what they want without unduly affecting me.
Spintz
I have no idea yet how many are to be displayed. I figure that I will need to do quite a bit of testing of the capabilities before deciding. I will also need to work out the balance between more of smaller patches (Spintz tiles) or fewer of large patches. Actually I have quite a bit to do (and learn) in this area. Is there a limit on the number of patch images the system can hold in memory, so is there are limit on the number of patches I can display? Lots to learn. When is your next version coming out? I like what I see with the speed improvements - that looks very promising indeed.
Thanks both of you for your comments and help. It is nice to know that I am not wandering down a blind alley.
Yes you are right it is confusing as too many of the terms are being used for more than one purpose. I use the term 'tile' to refer to my small terrain type tiles and patches to refer the much larger Spintz style tiles. I hope that distinction makes things clearer.
I need to have a map that can easily be generated, with discrete terrain types (for path finding, movement inhibiting, visibility rules etc) and that looks reasonably nice. To achieve this, I have a set of terrain types (which are associated with their graphics tile) and the underlying map is a map of these types plus a height map. Due to the size of the map that I want, it is unrealistic (I assume - I have not actually run tests of any kind) to try and display all at once so I need some form of LOD. As I want to hide the edges between tiles I figure that I need to do some kind of preprocessing to the map before display (I dont imagine that I can achieve any kind of decent performance by doing it on the fly). I think there is a difference between what you are doing and I am doing in that as I intend using the underlying map to control positioning, movement etc I do not care if not every tile is shown completely accurately or not. So long as I can calculate the model's position for display purposes, I am happy. If in my preprocessing stage I produce a heightmap and medium size image to put on it, then the LOD effects can do what they want without unduly affecting me.
Spintz
I have no idea yet how many are to be displayed. I figure that I will need to do quite a bit of testing of the capabilities before deciding. I will also need to work out the balance between more of smaller patches (Spintz tiles) or fewer of large patches. Actually I have quite a bit to do (and learn) in this area. Is there a limit on the number of patch images the system can hold in memory, so is there are limit on the number of patches I can display? Lots to learn. When is your next version coming out? I like what I see with the speed improvements - that looks very promising indeed.
Thanks both of you for your comments and help. It is nice to know that I am not wandering down a blind alley.
This thread is a bit old but since you bring it up, you can use the texture mixer I use in my project if you like. The screenshot here is a quick sample:
Download (1.899 KB). The file is a bit big, because I included all the textures used in the sample program.
If you want to blend the textures based on data from a file instead of perlin noise, you just have to make a class with CTextureMixerData as base class and implement the three virtual methods.
Download (1.899 KB). The file is a bit big, because I included all the textures used in the sample program.
If you want to blend the textures based on data from a file instead of perlin noise, you just have to make a class with CTextureMixerData as base class and implement the three virtual methods.
I didnt continue my work on that generator (since I switched to Ogre for different reasons), but you can of course download and use it if you like (its only a small piece of code, just remember thats its far from completed and there may be bugs).
Download: Texture-Generator
At the current version its just generating a texture from different height regions, no cliffs etc. are used, in addition to that I used a simple macro to define the texture size (check the implementation header) - so if you wish smaller (or larger?) textures you need to change this and remcompile or simply save it at runtime (like I said, I didnt plan to continue). I post a small code on how to use it with the terrain tutorial..
Instead of "terrain->setMaterialTexture" use this (you can also see it in the main.cpp):
addGroundRegion accepts the texture, the base height and the range (height).. all together you map is 256 units high, so all these values should cover all 256 units, otherwise you get black texture parts - if there are more than 2 textures mixed on a specific range it will result in an overflow and you will get black or pink texture parts (otherwise you can add as many textures you like).
I know its a bit of pain this way, I planned to use a better (an easier) way.. but I never started this. If you want to continue developing or just have some question, mail me - fantadan at gmail dot com.
Download: Texture-Generator
At the current version its just generating a texture from different height regions, no cliffs etc. are used, in addition to that I used a simple macro to define the texture size (check the implementation header) - so if you wish smaller (or larger?) textures you need to change this and remcompile or simply save it at runtime (like I said, I didnt plan to continue). I post a small code on how to use it with the terrain tutorial..
Instead of "terrain->setMaterialTexture" use this (you can also see it in the main.cpp):
Code: Select all
// NEW: create texture generate and create custom texture
scene::ITerrainTextureGenerator* generator = new scene::CTerrainTextureGenerator(driver);
if( generator != 0 )
{
// NEW: add ground region-textures
generator->addGroundRegion(driver->getTexture("../../data/grass.bmp"), 0, 128);
generator->addGroundRegion(driver->getTexture("../../data/rock.jpg"), 128, 128);
generator->addGroundRegion(driver->getTexture("../../data/snow.bmp"), 255, 128);
// NEW: generate texture
video::ITexture* t = generator->generateTexture(
driver->getTexture("../../data/terrain-heightmap.bmp"));
// CHANGED: set new texture here
terrain->setMaterialTexture(0, t);
// NEW: generator is not needed anymore
delete generator;
}
I know its a bit of pain this way, I planned to use a better (an easier) way.. but I never started this. If you want to continue developing or just have some question, mail me - fantadan at gmail dot com.