Editable Terrain Manager [v2.2 released]
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Trosan, what graphics card do you have? Passes on the terrain are expensive, and you need a good graphics card to cope with them. That being said, I did use 36 splat textures on a 128x128 map once on a 6600GT (for testing purposes) which were 6+1 (lighting map) passes, and I could still move fluidly over the terrain (no idea about the framerate, I did not have a fps display active).
Well, you'll have to decide what you want. For one thing, you could limit the amount of textures to use to 6-12. If the textures are good and diverse, then this is easily enough to create nice looking terrains, and it's also easier on slower graphics cards. You could also multiply them by a colour map so you get a bit of variation by colouring the terrain on top of a few base textures. Or you'll just need to target higher graphics hardware
Just out of curiosity: What size are the textures you used?
Well, you'll have to decide what you want. For one thing, you could limit the amount of textures to use to 6-12. If the textures are good and diverse, then this is easily enough to create nice looking terrains, and it's also easier on slower graphics cards. You could also multiply them by a colour map so you get a bit of variation by colouring the terrain on top of a few base textures. Or you'll just need to target higher graphics hardware
Just out of curiosity: What size are the textures you used?
-
- Greenskin
- Posts: 149
- Joined: Sat Apr 14, 2007 1:27 pm
My card(FX5200) for example supports shader model 2.0 but its a joke. A pixel shader with 1 addition in it runs slower than 4 alpha splats on the fixed function pipeline.
Realtime shaders are still quite new, so thats why alot of games have settings where no shaders are used.
But dont let that scare you, newer cards have greatly improved shader support.
Realtime shaders are still quite new, so thats why alot of games have settings where no shaders are used.
But dont let that scare you, newer cards have greatly improved shader support.
-
- Greenskin
- Posts: 101
- Joined: Sun Jun 10, 2007 4:57 pm
- x 1
Okay, it can't harm to learn a bit about shader programming anyway, so I will try and see if this gives me the performance boost I am aiming for.you could put them 4x4 into a 1024x1024 texture and sample it multiple times per pass
Yep, that's the way to go if you want to get the best performance.
I've ran into this problem when using texture atlases with direct OpenGL programming already (though I stopped working on that before quite solving it). I hope that extending each textures to it's edges (i.e. a direct copy of each outer pixel) might solve it. That's my first idea at least..Although that introduces a slight complication - the textures within the atlas will need to be specially prepared to avoid typical problems associated with texture atlases
Mobility Radeon 9600Trosan, what graphics card do you have?
Supports Shader v2, but was the first (notebook) card which did (I think it's the laptop version of Radeon 9800 IIRC).
Your card is definitely better than mine.
Hum... I think I need 20, perhaps 18 (two could be left out easily).Well, you'll have to decide what you want. For one thing, you could limit the amount of textures to use to 6-12.
Sounds interesting, I guess it's one more pass, though? (such as the lighting one)You could also multiply them by a colour map so you get a bit of variation by colouring the terrain on top of a few base textures.
Hm.. I will probably not release anything within the next year, so this might be an option. Not a preferred one, though.Or you'll just need to target higher graphics hardware
128x128 atm.Just out of curiosity: What size are the textures you used?
Last edited by Trosan on Sun Jul 22, 2007 5:27 pm, edited 2 times in total.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
You could also follow HexiDave's advice and see if you can divide your terrain into separate areas. For example, you could subdivide the terrain into 4 different areas, where each area needs only 6 textures (but those 6 textures can differ between the different areas). That way, you've effectively also cut down the number of passes while still keeping a great variety on textures IF you can divide them like that. Of course, it's more difficult to generate the texturing that way.
The way you'd do this with ETM is create separate TerrainManagers for the subareas of your terrain and place them so that they tie in at the edges. This may give ugly edges with LOD, but I'll fix that with the next version.
The way you'd do this with ETM is create separate TerrainManagers for the subareas of your terrain and place them so that they tie in at the edges. This may give ugly edges with LOD, but I'll fix that with the next version.
-
- Greenskin
- Posts: 101
- Joined: Sun Jun 10, 2007 4:57 pm
- x 1
(me = stupid - posted in the wrong thread o_O)
I was up to aggreeing with you, until I figured that my own card is not capable of using ps_2_x.. :-/
No, buying a new PC is no option for me atm (I am currently on laptop, that's why I can't simply upgrade the card). That's a problematic situation, hehe.
Well, I have just started to learn to cheat... I was hoping for my shader to be bad-optimized or something that could be easily fixed, but HexiDave has told me that coding 3D apps is no cakewalk, so I must not complain.
Trosan wrote:Alright, I've tried and written a shader now. Unfortunately, it's not working as I'd like it to (also has its limitations... :-/).
First, here's the shader:It's based on stoneCold's one.Code: Select all
void main ( float2 iTexCoord0 : TEXCOORD0, out float4 oColor : COLOR, uniform sampler2D covMap1, uniform sampler2D covMap2, uniform sampler2D covMap3, uniform sampler2D covMap4, uniform sampler2D texatlas0, uniform float splatScaleX, uniform float splatScaleZ //uniform float textureDimX, //uniform float textureDimY ) { float3 cov1, cov2, cov3, cov4; float2 texdim3; float2 texcoords[8]; float2 test; float2 test2; float textureDimX = 128; //parameter eventually float textureDimY = 128; cov1 = tex2D(covMap1, iTexCoord0).rgb; cov2 = tex2D(covMap2, iTexCoord0).rgb; cov3 = tex2D(covMap3, iTexCoord0).rgb; cov4 = tex2D(covMap4, iTexCoord0).rgb; iTexCoord0.x *= splatScaleX / 8; iTexCoord0.y *= splatScaleZ / 8; texdim3.x = textureDimX / 1024; texdim3.y = textureDimY / 1024; test.x = (iTexCoord0.x + 1) / texdim3.x; test.y = (iTexCoord0.y + 1) / texdim3.y; for ( int idx = 0; idx < 8; ++idx ) { texcoords[idx].x = iTexCoord0.x - texdim3.x * int( test.x -idx ); texcoords[idx].y = iTexCoord0.y - texdim3.y * int( test.y -idx ); } oColor = tex2D(texatlas0, texcoords[0]) * cov1.x + tex2D(texatlas0, texcoords[1]) * cov1.y + tex2D(texatlas0, texcoords[2]) * cov1.z /*+ tex2D(texatlas0, texcoords[3]) * cov2.x + tex2D(texatlas0, texcoords[4]) * cov2.y + tex2D(texatlas0, texcoords[5]) * cov2.z*/; }
The last three instructions are commented out because:
- uncommenting all three, the Cg compiler complains about "Instruction limit of 96 exceeded - 107 instructions needed"
- uncommenting only two causes an exception during runtime (something with 'invalid registers' and "read of uninitialized component")
Please tell if I should better ask in a different thread and not pollute this one, I am getting away from the topic I'm afraid.
Jon wrote:Looks like it is time to select a larger shader model, in the material
add a profile like
Note that this means the shader will not run on older hardware which does not support that shader model. One either provides more than one shader program (so that it can fallback to a more basic shader), or just let the fixed function code handle it.Code: Select all
profiles ps_2_x
Personally (and people may hate me for this) I don't worry about requiring any shader model which a $30 graphics card can support. Now that means that older notebooks are left out in the cold, but if there will always be such machines.
I was up to aggreeing with you, until I figured that my own card is not capable of using ps_2_x.. :-/
No, buying a new PC is no option for me atm (I am currently on laptop, that's why I can't simply upgrade the card). That's a problematic situation, hehe.
Well, I have just started to learn to cheat... I was hoping for my shader to be bad-optimized or something that could be easily fixed, but HexiDave has told me that coding 3D apps is no cakewalk, so I must not complain.
- Jon
- Goblin
- Posts: 227
- Joined: Mon Oct 10, 2005 5:07 am
- Location: Texas
There are profiles below ps_2_x, I just picked that because I have a shader handy which uses that, and I wanted to make sure of the material syntax before posting.
The limits of the shaders do present a challange, getting the most out of the hardware has always been a central issue of computer graphics.
As an aside, I have found the Cg compiler does a good job of optimising, so that it is rare that I can go back through a shader and shave anything off.
Looking at the shader, I wonder if splitting up the oColor calculation into multiple statements would help. The Cg compiler may feel that it has to have all of the subexpressions in registers at the same time, as opposed to doing one texture lookup, assigning, and then moving onto the next texture lookup.
The limits of the shaders do present a challange, getting the most out of the hardware has always been a central issue of computer graphics.
As an aside, I have found the Cg compiler does a good job of optimising, so that it is rare that I can go back through a shader and shave anything off.
Looking at the shader, I wonder if splitting up the oColor calculation into multiple statements would help. The Cg compiler may feel that it has to have all of the subexpressions in registers at the same time, as opposed to doing one texture lookup, assigning, and then moving onto the next texture lookup.
-
- Greenskin
- Posts: 101
- Joined: Sun Jun 10, 2007 4:57 pm
- x 1
The problem is, I am already using ps_2_0
I will look for a different solution now - I can't be the only one with this problem, can I?
Thanks, I tried that, but it didn't help.Looking at the shader, I wonder if splitting up the oColor calculation into multiple statements would help. The Cg compiler may feel that it has to have all of the subexpressions in registers at the same time, as opposed to doing one texture lookup, assigning, and then moving onto the next texture lookup.
I will look for a different solution now - I can't be the only one with this problem, can I?
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
- hanckjt
- Gnoblar
- Posts: 15
- Joined: Mon Nov 06, 2006 4:01 pm
- Location: China
- Contact:
CABAListic, I need your help, please.
How did I use the MiniMap.
I try it like this:
But m_imgMiniMap is the same as LightMap, no textures.
How did I use the MiniMap.
I try it like this:
Code: Select all
Image imgColorMap;
ET::SplattingManager* pSplattingManager = GetSplattingManager();
int iTextureNums = pSplattingManager->getNumTextures();
ET::ColourList vColorList( iTextureNums, ColourValue::White );
pSplattingManager->createColourMap( imgColorMap, vColorList );
m_imgMiniMap = ET::createMinimap( imgColorMap, GetLightMap() );
-
- Gremlin
- Posts: 158
- Joined: Tue Jan 17, 2006 12:09 am
Would it be possible to save the final output image of the terrain in the editor? I don't need to dynamically change the shape of the terrain, so I could skip the texture passes, and just generate a texture for the terrain with all the passes already applied.
Anyone knows how I can get this final image?
Anyone knows how I can get this final image?
- AntonTheManton
- Greenskin
- Posts: 100
- Joined: Sun Jan 14, 2007 1:47 am
Superb
I have been fiddling with the Manager for a couple of evenings, and I must say, it is absolutely superb. Great features, great and simple interface, it actually compiles, great demo.
I was able to drive my tanks over the terrain using the same code that is used to semi-float the Ogre head over the terrain, with no problems - I was a little bit worried after reading all those complex posts about collisions.
Re: slowness. I don't think it is an issue, as I have discovered that the terrain in the sample is actually of a massive size (the large ogre head makes it look small) compared to my existing terrain, which was going much faster.
I'm definitely going to use your library for my simulation engine. I'm going to build some extensions to generate craters and piled dirt. I will also look at decals at some point.
Both thumbs are up! (Readers will note that I give most people the double thumbs down).
I was able to drive my tanks over the terrain using the same code that is used to semi-float the Ogre head over the terrain, with no problems - I was a little bit worried after reading all those complex posts about collisions.
Re: slowness. I don't think it is an issue, as I have discovered that the terrain in the sample is actually of a massive size (the large ogre head makes it look small) compared to my existing terrain, which was going much faster.
I'm definitely going to use your library for my simulation engine. I'm going to build some extensions to generate craters and piled dirt. I will also look at decals at some point.
Both thumbs are up! (Readers will note that I give most people the double thumbs down).
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Thanks a lot Glad you like the interface, that was the primary reason why I abandoned the scene manager route in the first place.
@ricardo: I'm not entirely sure what you mean. Do you mean generating a base texture from the coverage maps and the splatting textures? Due to the restrictions of texture size this texture applied to the terrain instead of splatting will most likely look nowhere near as good, although it's a viable option for a LOD approach (save splatting in the distance). Anyway, there's no functionality to generate such a base texture in ETM. You can do this yourself, all you need are the coverage maps and the splatting textures. A possible approach might be to resize the coverage maps to the target size of your base texture, then traverse them pixel by pixel, calculate the pixel index in your splatting textures to use and combine the pixels there by what the coverage maps say.
@ricardo: I'm not entirely sure what you mean. Do you mean generating a base texture from the coverage maps and the splatting textures? Due to the restrictions of texture size this texture applied to the terrain instead of splatting will most likely look nowhere near as good, although it's a viable option for a LOD approach (save splatting in the distance). Anyway, there's no functionality to generate such a base texture in ETM. You can do this yourself, all you need are the coverage maps and the splatting textures. A possible approach might be to resize the coverage maps to the target size of your base texture, then traverse them pixel by pixel, calculate the pixel index in your splatting textures to use and combine the pixels there by what the coverage maps say.
-
- Gnoblar
- Posts: 11
- Joined: Thu Apr 05, 2007 5:37 am
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
-
- Gnoblar
- Posts: 11
- Joined: Thu Apr 05, 2007 5:37 am
-
- Gnoblar
- Posts: 11
- Joined: Thu Apr 05, 2007 5:37 am
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
- AntonTheManton
- Greenskin
- Posts: 100
- Joined: Sun Jan 14, 2007 1:47 am
Fog in ETM
I'm just wondering if the Fog shader posted earlier will be merged into the ETM code? (Before I go and write my own one).
I'm also using OpenGl, so thanks for posting the tip about the shader issue.
Great Work
I'm also using OpenGl, so thanks for posting the tip about the shader issue.
Great Work
- AntonTheManton
- Greenskin
- Posts: 100
- Joined: Sun Jan 14, 2007 1:47 am
Camera Height Bug in Demo
By the way - my camera follows the terrain no problem, but I'm not attached to a SceneNode. Perhaps "Camera::getDerivedPosition()" would give a more accurate position than "SceneNode::getPosition()".
Also - forcing a minimum cam height of 2.0 units above terrain is good for me (don't need 30.0).
Also - forcing a minimum cam height of 2.0 units above terrain is good for me (don't need 30.0).
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Well, since shaders are not technically a part of the ETM code base, it's not my current primary concern. Eventually I'll have to touch the demo again and make it a bit more complete, and then I might also see about including fog in the example material. But in any case, I'd always recommend to write your own material and shaders for your specific needs
As for the camera movement, I more or less took that setup from the Ogre tutorials. In theory, since the mved scene node is created from the root, its position should be identical to the Camera's position. But since in the demo the camera can sometimes dive through the terrain, something's flawed with that, it seems
As for the camera movement, I more or less took that setup from the Ogre tutorials. In theory, since the mved scene node is created from the root, its position should be identical to the Camera's position. But since in the demo the camera can sometimes dive through the terrain, something's flawed with that, it seems
-
- Gremlin
- Posts: 158
- Joined: Tue Jan 17, 2006 12:09 am
Well, What I've done is to simply take a screenshot using an orthogonal viewport, and changed the code a bit to allow for bigger textures size.CABAListic wrote:...
@ricardo: I'm not entirely sure what you mean. Do you mean generating a base texture from the coverage maps and the splatting textures?
...
IT's good enough for our project, because it is combined afterwards with a detail texture. We want to be able to support video cards with no pixel shader support (S3, intel graphics type of stuff).
Good job with ETM.
-
- Gremlin
- Posts: 158
- Joined: Tue Jan 17, 2006 12:09 am
I have a problem getting the max value of a texel, in loadHeightmapFromImage:
If bpp = 4, then it will be 2^32 - 1, equal to 0 (because of uint's size).
I'm using VC++ Express. Anyone else had this problem?
If I change it to this, it works:
Code: Select all
unsigned int maxVal = (1 << (bpp*8)) - 1;
I'm using VC++ Express. Anyone else had this problem?
If I change it to this, it works:
Code: Select all
Ogre::Real maxVal = Ogre::Math::Pow(2,bpp*8 ) - 1;
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact: