Editable Terrain Manager [v2.2 released]
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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
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
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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)
Getting Terrain Dimensions specified in the CFG file. I use this for positioning the camera when loading up a terrain:
Clearing the geometry via setWorldGeometry:
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:
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
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")
...
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")
...
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;
}
...
Also, regarding these options:
Code: Select all
# Specify the size of the terrain
Width=129
Height=129
Sorry for all the questions!
KungFooMasta
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Great, I'll integrate them into my code base.
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".
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.
Strange, they were definitely there. Must have gotten lost at the last moment...I had to add the following dependencies to get rid of linker problems.
OgreGUIRenderer.lib
CEGUIBase.lib
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 setOption method. Note that if you don't create a new MaterialHandler, crash occurs when loading terrain. (Repro: LoadTerrain, ClearTerrain, LoadTerrain)
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 availableClearing the geometry via setWorldGeometry:
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 performanceI 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?
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".
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.Is this the size of the coveragemap + 1? I see ETterrain.Tex.0.png is 128x128 pixels, so I'm just guessing.
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
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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
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
- Silver Sponsor
- Posts: 2703
- Joined: Mon Aug 29, 2005 3:24 pm
- Location: Kuala Lumpur, Malaysia
- x 51
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: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?
1) 4 passes - hovering around 17-20 FPS
2) 1 pass (only 1 texture no shader) - 35-40 FPS.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Do you mean like a base texture that is used in the distance? That would require modifications to the material handler.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.
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.
-
- Silver Sponsor
- Posts: 597
- Joined: Sun Jan 07, 2007 11:55 pm
- Location: Cologne, Germany
- Contact:
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 factorsKungFooMasta 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?
Enough is never enough.
-
- Gnoblar
- Posts: 12
- Joined: Tue Jan 23, 2007 11:59 pm
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
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
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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
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
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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
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
- Gnoll
- Posts: 653
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 36
- Contact:
Awesome! Exactly what we need
ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
Support me on Patreon
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
@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.
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.
-
- OGRE Contributor
- Posts: 265
- Joined: Sun Mar 25, 2007 1:48 pm
- x 2
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
-
- OGRE Contributor
- Posts: 265
- Joined: Sun Mar 25, 2007 1:48 pm
- x 2
@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:
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:
This rings a bell somehow... but might quite likely be part of some basic 3d math thingy I am ignorant of.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.
-
- OGRE Expert User
- Posts: 557
- Joined: Wed May 05, 2004 3:19 pm
- Location: Portland, OR, USA
- Contact:
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
Doing it this way would avoid the stretching that happens with the usual texturing techniques (I think).
Chaster
-
- Gnoblar
- Posts: 14
- Joined: Fri Sep 08, 2006 9:42 am
- Location: Thüringen/Germany
- Contact:
-
- OGRE Contributor
- Posts: 265
- Joined: Sun Mar 25, 2007 1:48 pm
- x 2
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???
Maybe it is more like a cubemap???
-
- Gnoblar
- Posts: 2
- Joined: Mon Jan 27, 2003 3:16 pm
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
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
-
- Gnoblar
- Posts: 14
- Joined: Fri Sep 08, 2006 9:42 am
- Location: Thüringen/Germany
- Contact:
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
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
-
- Gremlin
- Posts: 185
- Joined: Sat May 07, 2005 3:27 pm
Could you please explain to what (vertex / mesh / other ?) these texgen_planes are attached ?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.
-
- Gremlin
- Posts: 185
- Joined: Sat May 07, 2005 3:27 pm
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 :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???
Code: Select all
U(x,y,z) = plane[0] * [x,y,z];
V(x,y,z) = plane[1] * [x,y,z];
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
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?