Editable Terrain Manager [v2.2 released]

[KungFooMasta]

Something really small that I'll toss in tonight is to accept some kind of option to delete the terrain. You have the function there, but there is no way to clear just the terrain. In my editor when you start a new scene there should be no terrain.

if( name == "ClearTerrain" )
{
deleteTerrain();
}

or something like that.

Alternatively, you can make setWorldGeometry("") do it. Not sure what the most appropriate way of clearing the terrain would be.

KungFooMasta

[KungFooMasta]

Got the demo running, works great! I had to add the following dependencies to get rid of linker problems.

OgreGUIRenderer.lib
CEGUIBase.lib

Also, I was able to integrate it into my app, and it works great with OgreOpcode!

Here are some minor changes I made to your code, if you wish to integrate it, or for others who might need similar functionality:

Clearing the Geometry via setOption method. Note that if you don't create a new MaterialHandler, crash occurs when loading terrain. (Repro: LoadTerrain, ClearTerrain, LoadTerrain)

Code: Select all

bool ETSceneManager::setOption(const String& name, const void* value)
  {
	if (name == "ClearWorldGeometry")
	{
	  deleteGeometry();
	  // create a new material handler
	  mMaterialHandler = new ETMaterialHandler(getName()+"/Materials/Terrain", ResourceGroupManager::getSingleton().getWorldResourceGroupName(), this, mOptions);
	  return true;
	}
    else if (name == "BrushArray")
    ...

Getting Terrain Dimensions specified in the CFG file. I use this for positioning the camera when loading up a terrain:

Code: Select all

bool ETSceneManager::getOption(const String& name, void* value)
  {
	if (name == "GetTerrainDimensions")
	{
	  Vector3& vec = *static_cast<Vector3*>(value);
	  vec.x = mOptions.scale.x * (mOptions.width - 1);
	  vec.y = mOptions.scale.y;
	  vec.z = mOptions.scale.z * (mOptions.width - 1);
	}
    else if (name == "GetLightmap")
    ...

Clearing the geometry via setWorldGeometry:

Code: Select all

void ETSceneManager::setWorldGeometry(const String& filename)
  {
	if (filename=="") 
	{
	  // delete the currently loaded terrain
	  deleteGeometry();
	  // create a new material handler
	  mMaterialHandler = new ETMaterialHandler(getName()+"/Materials/Terrain", ResourceGroupManager::getSingleton().getWorldResourceGroupName(), this, mOptions);
	  return;
	}
	...

I saw what the tiling setting does. Is it possible to use a colormap and then splat it with 4 textures? Otherwise max textures we have for terrain is 4, right?

Also, regarding these options:

Code: Select all

# Specify the size of the terrain
Width=129
Height=129

Is this the size of the coveragemap + 1? I see ETterrain.Tex.0.png is 128x128 pixels, so I'm just guessing.

Sorry for all the questions!

KungFooMasta

[CABAListic]

Great, I'll integrate them into my code base.

I had to add the following dependencies to get rid of linker problems.

OgreGUIRenderer.lib
CEGUIBase.lib

Strange, they were definitely there. Must have gotten lost at the last moment...

Clearing the Geometry via setOption method. Note that if you don't create a new MaterialHandler, crash occurs when loading terrain. (Repro: LoadTerrain, ClearTerrain, LoadTerrain)

Seems I didn't really plan out for emptying the terrain. Recreating the material handler at that place seems kind of hacky, I'll probably have to alter that so that a call to deleteGeometry really is all that's needed there.

Clearing the geometry via setWorldGeometry:

If the functionality is available via setWorldGeometry, is there any reason it needs to be offered via setOption, too? Because I find the setOption/getOption interface slightly clumsy, as long as an alternative is available

I saw what the tiling setting does. Is it possible to use a colormap and then splat it with 4 textures? Otherwise max textures we have for terrain is 4, right?

I'm not entirely sure what you mean here. Currently, for every 4 textures the ETSM uses one dynamically created coverage map. You can define as many textures as you want, but every set of four incurs another pass on the terrain, costing performance
Try adding more textures in the ETterrain.cfg, you can then use a larger vector<float> for the channels to modify. You might need to comment out the line "CoverageBasename=..." because I believe that the coverage loading code fails if there are not enough coverage maps for the number of textures you are using; if you comment it out, the ETSM will create empty ones in memory which you can then save to disk with setOption "SaveCoverage".

Is this the size of the coveragemap + 1? I see ETterrain.Tex.0.png is 128x128 pixels, so I'm just guessing.

Basically, yes. It's actually the number of vertices that the terrain is made of in x and z directions and therefore also the size of your terrain heightmap data.
This is equivalent to the PageSize option of the TSM and PLSM, except that you can use non-square terrain sizes and also sizes like 193 that TSM and PLSM would reject.

[KungFooMasta]

There doesn't have to be 2 methods to clearing the terrain, I use the setWorldGeometry("") method myself.

Ok, so width and height should be the same as Heightmap pixel dimensions, good to know.

For the Splatting Textures, I'm extremely noob with my knowledge on its usage. I was asking if it's possible to generate a colormap (texturemap) via L3DT or any terrain generator, and then do splatting on top of that map.

I was thinking I was limited to 4, that's cool if I can go higher. What is the max number of passes, is that hardware dependent? What would be the max passes on a high end graphics card today?

Thanks again,

KungFooMasta

[syedhs]

I was thinking I was limited to 4, that's cool if I can go higher. What is the max number of passes, is that hardware dependent? What would be the max passes on a high end graphics card today?

I have personally developed an app with terrain utilizing texture with 4 passes. Well I dont know if there is any limit, but the more passes you have the slower they get. Therefore, it is much better to limit to 4 texture unit and have them splatted using shader with only 1 pass. I havent' tried it myself, but 4 passes down to 1 pass will definitely see a lot of FPS increase. A brief stats:

1) 4 passes - hovering around 17-20 FPS
2) 1 pass (only 1 texture no shader) - 35-40 FPS.

[CABAListic]

For the Splatting Textures, I'm extremely noob with my knowledge on its usage. I was asking if it's possible to generate a colormap (texturemap) via L3DT or any terrain generator, and then do splatting on top of that map.

Do you mean like a base texture that is used in the distance? That would require modifications to the material handler.

Anyway, as syedhs put it, passes on the terrain do cost performance. How much depends on the terrain size and your graphics card. I would assume that two to three passes should usually be no problem for terrain sizes of up to 513x513, unless you are targetting older hardware (but that might well not have a v2 pixel shader, so would not be supported by ETSM's material, anyway). So, with two to three passes you'd have 8 to 12 textures to your disposal. If terrain sizes are smaller, you can probably go higher still.

[jjp]

I was thinking I was limited to 4, that's cool if I can go higher. What is the max number of passes, is that hardware dependent? What would be the max passes on a high end graphics card today?

In theory you can have as many passes as you want. 2 or 3 passes won't cause trouble on most gfx cards. In the end you'll have to test it yourself because obviously your framerate is tied to lots of other factors

[Ayrik]

I tried using your scene manager, but had an awful time getting it to work. I am using VS2003 so I made a project with the equivalent settings and got everything to compile for both ETSM and Sample. The Sample, however, did not run. It gave me a Windows Error, which I debugged and I guess it failed loading Direct3D Render System.

So I gave up on the Sample and integrated it into my own project, well, just loaded the plugin I suppose, but when Root goes to uninitialize it I get a crash...Seems kind of weird, though I did notice you have a few differences in your file structure, so I was wondering which version of Ogre you are using. My Ogre is v1-4, since I would prefer to stay with Eihort, what else do I need to do to get it to work? I have yet to play with it, only load and unload it (on shutdown).

Thanks....Sorry if it's too confusing.

- Ayrik

[CABAListic]

I'm using the SDK version of Eihort for VS2005. I have at this moment no idea how to help you. Technically it should work. Can you track the place where the error rises (debug)? That would be a start.

[KungFooMasta]

So you build the demo exe and the plugin dll. Move those into your SDK's release folder (assuming you built in release mode, ie ($OGRE_HOME)\bin\release)

Also you will need to add the plugin to the plugins.cfg file.
Also, you will need to move the necessary resources into the media folder, and include them in resources.cfg. You don't have to move the resources, but you do need to specify its location within the resources.cfg file.

It should be plug and play, I just built, moved to where the OGRE dll's are, setup resources, and ran the demo just fine.

KungFooMasta

[KungFooMasta]

CABAListic, some more questions regarding your awesome scene manager!

Does any functionality exist to dynamically add or remove Splatting Textures for use?

I see that when parsing the .cfg file you add the list of textures to ETMaterialHandler::mTextureList, and continue to create the material.

Can we come up with a way for there to be the following functions?

setOption("AddSplattingTexture",&SplatTextureFileName);
setOption("RemoveSplattingTexture",&SplatTextureFileName);

The idea is that I could have a library of textures and pick and choose which ones will be used for the terrain during run time. Is this doable? I ask because I am at work, and because you are more familiar with the code (obviously ). This weekend I will find time to attempt playing around with the code to see if I can achieve this, but there is a lot to digest. So far, it's pretty easy to read, just a lot to read.

KungFooMasta

[Nauk]

Awesome! Exactly what we need

[CABAListic]

@KungFooMasta:

The MaterialHandler was designed so that you can recall setupMaterial at any time with a new set of textures. But the according setOption is yet missing, I think. Easiest would be to have a setOption "SetTextures" (takes vector<String>) and pass this to mMaterialHandler->setupMaterial.

[Quall]

Great editor! Much better than me using gimp to tr and create a good terrain. If you get vertical texture mapping that was mentioned in this post then your manager and editor will be the best.

[beaugard]

Concerning the "vertical texture mapping" - does anyone have a ref. or an idea on how this would be achieved? My only idea would be 3d texture (which would work, of couse, but it feels stupid...), but maybe I am missing something obvious...?

[KungFooMasta]

@beaugard

Are you going to implement your metaball idea into ETSM?

KungFooMasta

[beaugard]

@KungFooMasta
Ehm, sure... just figure I should get it working in normal TSM first.

This texture mapping problem is driving me crazy, though. I am just sure there is a clever way of doing this that I am missing.
I downloaded the Grome Demo. I looked through the SDK docs for clues, but only came up with this from the sTextureMapping struct reference:

t_float4 texgen_planes[2]

Texture generation planes in case we are using texture mapping rotation.

This member contains 2 planes. Texture U coordinate is obtained by multiplying the vertex position with the first plane and V by multiplying it with the second. Not used when assigning the material (we are computing them from rotation). Used only when obtaining the texture channels.

This rings a bell somehow... but might quite likely be part of some basic 3d math thingy I am ignorant of.

[Chaster]

I'm not certain (that description is a bit dodgy), but it *sounds* to me like they are creating a plane which is parallel to the plane of each polygon in the mesh, and then projecting the polygon onto that plane, taking coordinates of each vertex (which are now 2D with respect to the plane) and using them as UV coordinates.

Doing it this way would avoid the stretching that happens with the usual texturing techniques (I think).

Chaster

[thbusch]

I think a simple solution to the vertical texture thing would be to create 2 more uv channels, one for (x,y) and one for (z,y) projection, should be easy to calculate those. You can then apply different splatting textures to those channels.
i'm new to ogre so i hope thart makes sense..

[beaugard]

yeah, but how do you choose which projection to use? The "normal" projection is (x,-1,z), which gives "smeared" texture mapping when y changes too much... so it is clear that we need something like (-1, y, z) when the normal faces one direction and (x, y, -1) when the normal faces 90 degrees away... but it needs to be seamless.

Maybe it is more like a cubemap???

[IHF]

With the caveat that I might be completely off:

If you have a point in space (vertex) with coordinates (a,b,c) and texture coordinates (u1,v1) and a point (d,e,f) where (u2, v2) is unknown.

To calculate (u2,v2) from (u1,v1) you would have to use the length of the vector (a,b,c)-(d,e,f) to make sure the texture follows the length of the surface defined by the vector - rather than just the movement over the ground plane, which is a lot shorter than the mentioned vector.

How to implement this - I don't know.

Cheers!
Ihf

[thbusch]

beaugard, i think that automatically blending between the directions would need a seperate texture pass for every direction and texture.
what about letting the user decide to which channel he wants a splat texture assigned to and let him paint that texture using the normal (x,-1,z) projection? i've tried to test that but had to give up due to my lack of ogre knowledge

[Shadow007]

@KungFooMasta
Ehm, sure... just figure I should get it working in normal TSM first.

I downloaded the Grome Demo. I looked through the SDK docs for clues, but only came up with this from the sTextureMapping struct reference:

t_float4 texgen_planes[2]

Texture generation planes in case we are using texture mapping rotation.

This member contains 2 planes. Texture U coordinate is obtained by multiplying the vertex position with the first plane and V by multiplying it with the second. Not used when assigning the material (we are computing them from rotation). Used only when obtaining the texture channels.

Could you please explain to what (vertex / mesh / other ?) these texgen_planes are attached ?

[Shadow007]

yeah, but how do you choose which projection to use? The "normal" projection is (x,-1,z), which gives "smeared" texture mapping when y changes too much... so it is clear that we need something like (-1, y, z) when the normal faces one direction and (x, y, -1) when the normal faces 90 degrees away... but it needs to be seamless.

Maybe it is more like a cubemap???

Nope ... My understanding is the following : it's exactly what you're telling : for each vertex/ face ? the projection is given by the "plane" thingies :

Code: Select all

U(x,y,z) = plane[0] * [x,y,z];
V(x,y,z) = plane[1] * [x,y,z];

Where plane[0], plane[1] are fixed for each vertex ... (maybe corresponding to the normal ?)

[CABAListic]

Forgive me if I'm missing the point (I'm by no means an expert for texture projection etc. ), but how would you actually make a projection from any other plane than the x-z plane work? For every unique (x, z) value you can find a unique spot of terrain, it's an injective mapping. But for any values (x, y) or (y, z) this is not the case. Imagine two moutains behind each other, with differing heights. How would you use individual textures for the two if you map vertically, when you cannot distinguish between them?