Advanced Terrain Textures
Advanced Terrain Textures
I'm sorry if this has been posted before... I'm working for some months with Irrlicht now and I just took a look at the terrain engine. The terrain included is *just* a LOD terrain which consist of patches.. but the texture is stretched over the entire heightmap (which is far from detailed). Am I missing something or is there an implementation of a more advanced way?
I'm asking this because I am planning to write a *new* terrain implementation (maybe based on the current terrain source) with detailed terrain (many textures for each patch/quad blended together) and features like adding paths etc. with colormaps, texture-generation of course and stuff - but I dont want to do it again if someone already did it. I read something about irrSpintz etc... maybe you can help me (I really tried searching the forums but the search function is somehow messed up, I get really weird results there)
I'm asking this because I am planning to write a *new* terrain implementation (maybe based on the current terrain source) with detailed terrain (many textures for each patch/quad blended together) and features like adding paths etc. with colormaps, texture-generation of course and stuff - but I dont want to do it again if someone already did it. I read something about irrSpintz etc... maybe you can help me (I really tried searching the forums but the search function is somehow messed up, I get really weird results there)
texture splatting is the best for terrains, as far as I know. You can apply detail maps and/or scale texture coords for splat textures and detail maps. Detail maps are implemented in Irrlicht. IrrSpintz has alpha maps( texture splats materials ). It still needs improvement, but applying a texture on a per patch is difficult, as far as seaming up the textures and I don't know of a terrain editor which does this.
OK thanks... this is not what I am looking for, so this is what I am planning to do:
- a terrain node based on the existing node, but the terrain is not rendered with a single call, its divided in patches (already implemented) which all own their own material (=texture), therefore I need multiply render-calls (I have to see how much perfomance-loss I'll get)
- a terrain texture generator, you define textures for different heightregions, cliffs etc. and the generator will produce a realistic looking texture for each patch (already did that some time ago for my own game, only without patches)
- optionally some kind of colormap. you define a colormap+texture, then the texture is blended on main terrain texture (this way you can create streets, regions with special textures and so on)
I hope that this improves the texture quality of terrains
I do not hope that this lags performance (since I made bad expierience with Irrlicht and many scene nodes (= many render calls)
So you create you heightmaps with a heightmap-tool, but the textures are created 100% by irrlicht
- a terrain node based on the existing node, but the terrain is not rendered with a single call, its divided in patches (already implemented) which all own their own material (=texture), therefore I need multiply render-calls (I have to see how much perfomance-loss I'll get)
- a terrain texture generator, you define textures for different heightregions, cliffs etc. and the generator will produce a realistic looking texture for each patch (already did that some time ago for my own game, only without patches)
- optionally some kind of colormap. you define a colormap+texture, then the texture is blended on main terrain texture (this way you can create streets, regions with special textures and so on)
I hope that this improves the texture quality of terrains
I do not hope that this lags performance (since I made bad expierience with Irrlicht and many scene nodes (= many render calls)
So you create you heightmaps with a heightmap-tool, but the textures are created 100% by irrlicht
Hi !
I'm planning to do something a little bit similar to that also. I would like to have the terrain using multiple tiles (small tiles of 32X32 or 64X64) 'connected' together to make the all terrain. If you want an analogy, take for example the old 2D strategy games.
But, I don't think making a patch for all 'texture' is a good idea, the textures are too small for that. Rather, a patch should contain several tiles but fully contained in the patch.
I know that I'll need to make my own TerrainNode also and I plan to do that when I have more experience with Irrlicht (I just started to use it). But, still I'm interested in your result and maybe I can help a little bit.
I'm planning to do something a little bit similar to that also. I would like to have the terrain using multiple tiles (small tiles of 32X32 or 64X64) 'connected' together to make the all terrain. If you want an analogy, take for example the old 2D strategy games.
But, I don't think making a patch for all 'texture' is a good idea, the textures are too small for that. Rather, a patch should contain several tiles but fully contained in the patch.
I know that I'll need to make my own TerrainNode also and I plan to do that when I have more experience with Irrlicht (I just started to use it). But, still I'm interested in your result and maybe I can help a little bit.
-
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
Ced666, there is a TiledSceneManager for Ogre, maybe its source can help you further here.
See this thread for pictures: http://www.ogre3d.org/phpBB2/viewtopic. ... 4607#94607
See this threads for infos and source download: http://www.ogre3d.org/phpBB2/viewtopic. ... 4606#94606
See this thread for pictures: http://www.ogre3d.org/phpBB2/viewtopic. ... 4607#94607
See this threads for infos and source download: http://www.ogre3d.org/phpBB2/viewtopic. ... 4606#94606
This hinders performance a lot! The terrain implementation used to do this, which is why there was no problem with 16 bit indices, because each patch was it's own mesh. However, instead of 1 large drawPrimitive call, you make a call to drawPrimitive for every patch in your terrain. You will see large performance hits by doing this.Knobs wrote:- a terrain node based on the existing node, but the terrain is not rendered with a single call, its divided in patches (already implemented) which all own their own material (=texture), therefore I need multiply render-calls (I have to see how much perfomance-loss I'll get)
T2 Terrain Texture Creartion tool ( http://www.toymaker.info/html/texgen.html ) does this already, and it's free. Also every terrain editor out there, Freeworld, PnP, etc. does this also, to do in the 3D engine, is slow. In real time, it would be very, very slow. As a pre-processing step, it would slow down your loading times. I could see adding this as a feature for creating your own terrain editor, but for a game, it doesn't make sense.Knobs wrote:- a terrain texture generator, you define textures for different heightregions, cliffs etc. and the generator will produce a realistic looking texture for each patch (already did that some time ago for my own game, only without patches)
This is what I explained to you, Texture Splatting, or Alpha Maps. You'll find that the added rendersteps can slow down your terrain. Or you can keep a single renderpass at 2 or 3 stages, but then you have to do it multiple times and render your primitives again for each pass. Especially if you have separate textures for each patch, for example.Knobs wrote:- optionally some kind of colormap. you define a colormap+texture, then the texture is blended on main terrain texture (this way you can create streets, regions with special textures and so on)
Let's say you do 1 render pass per terrain patch, but you have 5 render stages in the single pass. Let's say your terrain is 8 patches wide and high, then you have 64 * 5 ( 320 ) render stages each frame. If you were did multi-pass rendering, and had 3 stages in the first render pass( for base, alpha and texture splat1 say ) and 2 stages in the second pass to add another alpha map and texture splat, then you still have 320 render stages, but you're also drawing your primitives 2x.
Point is, what you're proposing is not efficient for large terrains. I tried it.
Look at IrrSpintz. The TiledTerrainManager class already exists and works very well with the current Terrain Node. You can get direct access to each TerrainNode that is part of the TilerTerrainManager. Link to IrrSpintz in my sig.Ced666 wrote:Hi !
I'm planning to do something a little bit similar to that also. I would like to have the terrain using multiple tiles (small tiles of 32X32 or 64X64) 'connected' together to make the all terrain. If you want an analogy, take for example the old 2D strategy games.
But, I don't think making a patch for all 'texture' is a good idea, the textures are too small for that. Rather, a patch should contain several tiles but fully contained in the patch.
I know that I'll need to make my own TerrainNode also and I plan to do that when I have more experience with Irrlicht (I just started to use it). But, still I'm interested in your result and maybe I can help a little bit.
The code is also very easily transferrable to base Irrlicht engine.
Baal, no need to go to Ogre
-
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
Yea like I said, I also made some bad experience with many render calls (or like you said "drawPrimitive"), but thats the only chance to apply more than one texture to a terrain (or do you know a different way?).Spintz wrote: This hinders performance a lot! The terrain implementation used to do this, which is why there was no problem with 16 bit indices, because each patch was it's own mesh. However, instead of 1 large drawPrimitive call, you make a call to drawPrimitive for every patch in your terrain. You will see large performance hits by doing this.
Of course I wont do this in real-time! It's thought as a preprocessing step, and in my eyes it makes sense... sure there are some good texture generation tools, but my aim is a terrain with *very* detailed terrain, so I would need a generation tool that creates a lot of textures. So, in combination with a "patched" terrain it would be good to do this myself.Spintz wrote: T2 Terrain Texture Creartion tool ( http://www.toymaker.info/html/texgen.html ) does this already, and it's free. Also every terrain editor out there, Freeworld, PnP, etc. does this also, to do in the 3D engine, is slow. In real time, it would be very, very slow. As a pre-processing step, it would slow down your loading times. I could see adding this as a feature for creating your own terrain editor, but for a game, it doesn't make sense.
no, I dont mean extra primitives as layers on the map... you define those before you generate all textures, these "colormaps" are then written directly on the main texture, so in the end you have 1 single texture (for each patch) where all source textures are blended togetherSpintz wrote: This is what I explained to you, Texture Splatting, or Alpha Maps. You'll find that the added rendersteps can slow down your terrain. Or you can keep a single renderpass at 2 or 3 stages, but then you have to do it multiple times and render your primitives again for each pass. Especially if you have separate textures for each patch, for example.
exactly this is my fear, I'm trying it anyway. Since my game is some kind of an RTS (you see the terrain from above) it could work (since you only see some patches from above and you dont need to render far distances).Spintz wrote: Point is, what you're proposing is not efficient for large terrains. I tried it.
I also think you understand me wrong in some ways... I dont want to improve the existing terrain, I just want to create a very very detailed terrain (-textures). One part of this "task" is to use more than one texture (if you dont want to use textures larger than 4096x4096 or something).
Imagine the current terrain with a 256x256 heightmap, and a 1024x1024 texture for this terrain. So for 1 vertex of the heightmap you have 4 pixels of the texture. The final texture quality of the terrain will look very blocky, even if you use larger textures and smaller heightmaps the result wont change much (and the terrain gets smaller and smaller). Check this example (its from one of the tools you posted, not irrlicht, but irrlicht looks "nearly" the same).
this is because the texture is stretched over the entire map, it looks really ugly. what I want to produce is something like this (only watch the quality of the terrain textures, its a screen from settler5)
To get results like this, I have to render each patch with their own material *or* load an extremely large texture (which is not possible). So imagine I divide the 256x256 heightmap in 32x32 quads (patches), my texture generator creates 1024x1024 textures for each quad. In the example before we had 4 pixels for 1 vertex, in this case we would have 32 pixels for each vertex (so the quality is much much better).
OF COURSE the perfomance will drop and the loading time will increase, but you have a really detailed looking terrain (texture) and viewed from above the perfomance should be Ok. I already started coding on that, at the moment I'm converting my old texture generator to use it with Irrlicht, I will post some pics when I get the first results
Baal: yes I know I already looked at this terrain manager from Ogre but it doesn't do what I want and honnestly it is not so good written and do some really strange things like duplicate every file texture into smaller one (to be used for the mip-map algo).
Spintz: I know there is a tiled terrain manager but I don't know if this does what I'm looking for. I mean, I need to display a lot of small tiles (32 X 32 pixels) so the the terrain nodes you are speaking about are alos very small. Maybe I can give a try and look if this is feasible.
Thanks
Spintz: I know there is a tiled terrain manager but I don't know if this does what I'm looking for. I mean, I need to display a lot of small tiles (32 X 32 pixels) so the the terrain nodes you are speaking about are alos very small. Maybe I can give a try and look if this is feasible.
Thanks
Ced666 - So you're not looking for a fancy LOD terrain right? Just something to be able to piece a 2d array of tiles together?
Knobs - I think I understand exactly what you want. There's no reason you can't create terrain from heightmaps that are 65x65 or 33x33 or whatever 2^N+1 size and then render a bunch of them, tiled together with the TiledTerrainManager, and then each tile is it's own node, which has it's own texture. T2 is good for generating textures for a single tile, T2 does not handle tiled terrain.
Freeworld3D is trying to implement this, and we'll see how it is when it's done. PnP Terrain Creator already has this feature, haven't used it much tho, cause I'd have to buy it to do anything larger than 2x2 terrain.
Hmmm, I could show an example of this, gimme a day or 2.
Knobs - I think I understand exactly what you want. There's no reason you can't create terrain from heightmaps that are 65x65 or 33x33 or whatever 2^N+1 size and then render a bunch of them, tiled together with the TiledTerrainManager, and then each tile is it's own node, which has it's own texture. T2 is good for generating textures for a single tile, T2 does not handle tiled terrain.
Freeworld3D is trying to implement this, and we'll see how it is when it's done. PnP Terrain Creator already has this feature, haven't used it much tho, cause I'd have to buy it to do anything larger than 2x2 terrain.
Hmmm, I could show an example of this, gimme a day or 2.
I want to have something similar as Knob in fact (maybe not so advanced to make texture splatting and auto-generation of terrains). For example Warcraft III is a good comparison. Take a look at the screenshots here: http://www.blizzard.com/war3/screenshot ... arge.shtmlSo you're not looking for a fancy LOD terrain right? Just something to be able to piece a 2d array of tiles together?
So, this is a lot of 2D tiles but rendered on a 3D terrain.
I finished the basic texture generator (nothing special untill now) which I will use later on to generate textures for single patches. So my next aim is the extended terrain scene node which uses different materials for each patch (if this works (perfomance etc.) I will extend the generator so that the terrain looks more realistic) - here are some pics of generated textures applied to the tutorial-heightmap
@Spintz: you were talking about 16-bit indices... so what is the largest heightmap I can load with that (and draw them in a single pass)?
@Spintz: you were talking about 16-bit indices... so what is the largest heightmap I can load with that (and draw them in a single pass)?