Editable Terrain Manager [v2.2 released]

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
Post Reply
User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by 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

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by 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! :D

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

Sorry for all the questions!

KungFooMasta

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

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

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by 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

User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2702
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 47

Post by syedhs »

KungFooMasta wrote: 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
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Post by 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
Silver Sponsor
Silver Sponsor
Posts: 597
Joined: Sun Jan 07, 2007 11:55 pm
Location: Cologne, Germany
Contact:

Post by jjp »

KungFooMasta wrote: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 :)
Enough is never enough.

Ayrik
Gnoblar
Posts: 12
Joined: Tue Jan 23, 2007 11:59 pm

Post by 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
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

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

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by 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

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by 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. :wink:

KungFooMasta

User avatar
Nauk
Gnoll
Posts: 647
Joined: Thu May 11, 2006 9:12 pm
Location: Bavaria
x 25
Contact:

Post by Nauk »

Awesome! Exactly what we need :)

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Post by 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
Greenskin
Posts: 146
Joined: Wed Apr 06, 2005 11:55 pm

Post by 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
OGRE Contributor
OGRE Contributor
Posts: 265
Joined: Sun Mar 25, 2007 1:48 pm
x 2

Post by 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...?

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by KungFooMasta »

@beaugard

Are you going to implement your metaball idea into ETSM? :twisted:

KungFooMasta

beaugard
OGRE Contributor
OGRE Contributor
Posts: 265
Joined: Sun Mar 25, 2007 1:48 pm
x 2

Post by 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
OGRE Expert User
OGRE Expert User
Posts: 557
Joined: Wed May 05, 2004 3:19 pm
Location: Portland, OR, USA
Contact:

Post by 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
Gnoblar
Posts: 14
Joined: Fri Sep 08, 2006 9:42 am
Location: Thüringen/Germany
Contact:

Post by 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.. :oops:

beaugard
OGRE Contributor
OGRE Contributor
Posts: 265
Joined: Sun Mar 25, 2007 1:48 pm
x 2

Post by 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
Gnoblar
Posts: 2
Joined: Mon Jan 27, 2003 3:16 pm

Post by 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
Christian
Webmaster of the never updated site Game Design Documents
www.ihfsoft.com

thbusch
Gnoblar
Posts: 14
Joined: Fri Sep 08, 2006 9:42 am
Location: Thüringen/Germany
Contact:

Post by 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 :cry:

Shadow007
Gremlin
Posts: 185
Joined: Sat May 07, 2005 3:27 pm

Post by Shadow007 »

beaugard wrote:@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
Gremlin
Posts: 185
Joined: Sat May 07, 2005 3:27 pm

Post by Shadow007 »

beaugard wrote: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
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Post by 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?

Post Reply