Editable Terrain Manager [v2.2 released]

[CABAListic]

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?

[REiNDEeR]

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.

[Trosan]

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.

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.

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

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..

Trosan, what graphics card do you have?

Mobility Radeon 9600
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.

Well, you'll have to decide what you want. For one thing, you could limit the amount of textures to use to 6-12.

Hum... I think I need 20, perhaps 18 (two could be left out easily).

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.

Sounds interesting, I guess it's one more pass, though? (such as the lighting one)

Or you'll just need to target higher graphics hardware

Hm.. I will probably not release anything within the next year, so this might be an option. Not a preferred one, though.

Just out of curiosity: What size are the textures you used?

128x128 atm.

[CABAListic]

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.

[Trosan]

(me = stupid - posted in the wrong thread o_O)

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:

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*/;



}

It's based on stoneCold's one.


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.

Looks like it is time to select a larger shader model, in the material
add a profile like

Code: Select all

	profiles ps_2_x

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.

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]

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.

[Trosan]

The problem is, I am already using ps_2_0

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.

Thanks, I tried that, but it didn't help.

I will look for a different solution now - I can't be the only one with this problem, can I?

[Loockas]

Is it possible to turn on lighting somehow (i.e. using Caelum to light the terrain by the sun and darken it with an ambient light only)? I've tried to do it in the material file but no results..

[CABAListic]

Lighting needs vertex normals, I suppose, which are currently not defined. I'll add them in the next release.

[hanckjt]

CABAListic, I need your help, please.
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() );

But m_imgMiniMap is the same as LightMap, no textures.

[ricardo_arango]

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?

[AntonTheManton]

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).

[CABAListic]

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.

[wangpeibin]

in windowsxp,i used VS2003 to complie the ETM.But there is someting wrong like this:fatal error LNK1561: entry point must be define

who can help me? thank you!

[CABAListic]

Looks like it's trying to compile an executable which ETM is not. You need to make sure that the build target is a DLL.

[wangpeibin]

oh ,thank you very much. i see. i builded dll now.it is ok.
but i have a question:how to use this dll in my application ?

[wangpeibin]

i successfully complied the Demo_ETSM.
but when i run it,there is something wrong like this:Cannot locate aresource group called 'ET' for resource 'brush.png' in ResourceGroupManager````````````.
what is wrong ? who can help me ? thank you.

[CABAListic]

Included in the ETM zip file is a media/ET folder. You need to add this one to your resources.cfg as resource group ET.

To use the DLL in your application, you just add the accompanying .lib file to your linker process, just like OgreMain.lib.

[wangpeibin]

oh thank you very much!!

[AntonTheManton]

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

[AntonTheManton]

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).

[CABAListic]

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

[ricardo_arango]

...
@ricardo: I'm not entirely sure what you mean. Do you mean generating a base texture from the coverage maps and the splatting textures?
...

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.

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.

[ricardo_arango]

I have a problem getting the max value of a texel, in loadHeightmapFromImage:

Code: Select all

unsigned int maxVal = (1 << (bpp*8)) - 1;

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

Ogre::Real maxVal = Ogre::Math::Pow(2,bpp*8 ) - 1;

[CABAListic]

Are you certain? If bpp is 4, then 1 << 4*8 shifts the 1 32 positions left, which should give 0, if I'm not mistaken. Subtracting 1 from this gives -1 which is equivalent to the max value of an unsigned type.

But then, I didn't verify this, it's just the way it thought it should be