## 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!
thbusch
Gnoblar
Posts: 14
Joined: Fri Sep 08, 2006 9:42 am
Location: ThÃ¼ringen/Germany
Contact:
CABAListic wrote: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?
what if the user can supply a texture coordinates index to the textures in ETterrain.cfg, for example:
Texture0=splatting0.png coordxz
Texture1=splatting1.png coordxz
Texture2=splatting1.png coordxy
Texture3=splatting1.png coordyz

but the alpha map for the textures is mapped via the (x,z) coordinates.
that means you paint using the normal projection but the mapping ist done through the user-supplied projection.
makes that sense?

beaugard
OGRE Contributor
Posts: 265
Joined: Sun Mar 25, 2007 1:48 pm
x 2
<EDIT>
never mind, thbuschs beat me to it, and his description was much better.
</EDIT>
How would you use individual textures for the two if you map vertically, when you cannot distinguish between them?
I am not sure I understand this sentence, but if I do, this is the answer...

Anyhow, to just use raw x,y of a vertex as texture coordinates is no problem. The mountains in your example would have the same texture coordinates, but they would be tiled detail textures, so it does not reduce quality.

You would still used a (x,z) coverage map to determine which vertices are vertically texture mapped rock (for example).

The problem is how to find an optimal projection for each vertex, while not stretching the texture or creating cracks.

REiNDEeR
Greenskin
Posts: 149
Joined: Sat Apr 14, 2007 1:27 pm
I dont wanna point at anyone in specific here but im under the impression there are so many different projects of this type going on. Not suprising, alot of ppl need a good level editing / loading tool.

Cabalistic posts about his great achievements and immediatly I see ppl asking for his code to integrate it into their own editor.

Wouldnt it be better if we worked together to make a good standard level editor and a plugin?

Right now I have no idea what to go with and im getting to a point where Im also starting to think of making my own altho I dont want to.

I hope you get my point.

CABAListic
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:
Uh, this is not about a level editor. It's merely a scene manager that provides the basic capabilities needed for level editors.

Much as I like the idea of a general purpose level editor, I think that this is near to impossible to achieve. You may be able to abstract much of the functionalities, but there will always be something specific to your scenario not covered by a general purpose tool. That's why I decided to roll my own level editor for our project which in turn led to the development of the ETSM. And while our level editor is tied to our project and therefore not of much help to anyone else, the ETSM can be used for terrain editing in other projects

REiNDEeR
Greenskin
Posts: 149
Joined: Sat Apr 14, 2007 1:27 pm
The idea of a library is to abstract things to make it easier for other developpers. For example there are applications that cannot use a conventional graphics library such as OpenGL or Direct3D and have very little choice but to make their own, but that doesnt mean creating OpenGL was a bad idea.

This is true for any library, you have to abstract things and live with the fact not everybody will be able to use it.

You, the author(s) of PLSM and many others have found the need to create their own implementation of a technique which is widely used in 3D development because there is as far as I know no open library which does this.

I'm not sure why you said that, maybe your implementation has gotten to a point where its not abstract enough anymore to be used in another engine, but I dont think many ppl can deny the fact there is need for something like PLSM.

CABAListic
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:
I still think you mix up the ETSM with the screenshots of the level editor I posted?
Of course the Editable Terrain Scene Manager is an abstraction of both displaying and editing terrain along with a couple of convenience features like generating lightmaps. Of course this is not specific to any specific scenario and could be used by anyone who needs those features.

But a level editor is much more than that because it needs to generate a scene description which IS specific to your scenario. True, there are a couple of things you will almost always need (at least in a certain type of scenarios) that can be abstracted, but the abstraction usually also makes it more complex because it's a generic feature not explicitly tied to your needs. And you'll always find features that you need in your scene description that no general purpose editor would ever include.

I'm all for abstraction, but I do believe that too much abstraction doesn't work either. It'll get to a point where your abstraction layer is so far off from specific uses (to cover all grounds) that it gets complicated to use at all. That's why I'm NOT writing a general purpose level editor, merely a general purpose editable scene manager. And actually it's not even that, it doesn't support paging or anything like that because it simply doesn't fit the scope.

REiNDEeR
Greenskin
Posts: 149
Joined: Sat Apr 14, 2007 1:27 pm
I shouldnt have started posting in your thread, but I wasnt sure where to start a discussion about it, I was just annoyed about seeing ppl wanting to derive what you made instead of providing their help to make it better.

What I posted wasnt specificly about ETSM, I was speaking in general.

KungFooMasta
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:
CABAListic, I was playing around with the demo this weekend, and from what I remember, the brush size is dependent on either the size of the terrain, or the number of vertices in the terrain. Do you see the same thing?

For example, in my game I want to have a large world map, and was going to paint it/deform it using ETSM. I made the terrain huge (like 40000 x, 40000 z), and increased the resolution of the heightmap (huge, like 4096x4096). When I went to paint, the area that became painted was really far away, and was a massive splotch on the terrain. I've since then not needed such a high resolution heightmap (I'll make this in photoshop, world map is kind of dumbed down in details anyway), but I'd like to know the relationship between brush size, heightmap resolution size, and terrain size.

If possible, it would be great to make the brush size an absolute value in Ogre::Real. For example, a brush size of 10x10 would paint a 10x10 area in Ogre coordinate space. Ideally the amount of terrain that gets painted with a brush size of X should be the same regardless of terrain dimensions.

What are your thoughts on this?

KungFooMasta

CABAListic
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:
There is little point in making the sizes a Real value, because obviously the unit of terrain deforming is 1 vertex. Therefore, the brush size directly corresponds to your vertex count. A 10x10 brush will affect 10x10 vertices, no matter how you choose the scaling of the map.

As for terrain painting, the coverage maps that the ETSM use also have the dimensions of your heightmap (-1), therefore the brush size is also basically the same as for deforming. One COULD use higher resolution coverage maps and then could translate Real values to the coverage texture in more detail. But I like to keep things consistent, and besides, with your terrain size the coverage maps already would be 4096x4096 pixels which is, as far as I know, the maximum texture size today's graphics cards can handle...

KungFooMasta
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:
Ok, so the size of the paintbrush is the number of vertices to effect. But splatting doesn't have to cover an entier face, does it? What is minimum brush size to see splatting?

I have a feature request!

Can we somehow display the wireframe of the terrain as well as the texture at the same time? It would be a pretty awesome feature to be able to toggle this on and off, and would help me understand how the brush size works against the terrain for deforming and painting.

I don't know how to do this, but I see it being done in this screenshot of the netherforce editor:

http://www.netherforce.com/images/editor_path.jpg

Does anybody know how this can be done? Can we add this to ETSM?

KungFooMasta

CABAListic
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:
Apart from the wireframe rendering that Ogre::Camera offers, I'm afraid I don't have anything else to offer. The Netherforce shot probably puts objects or 3D lines on top of the terrain. You could probably construct something like that, doesn't need to be in the scene manager, I think.

Well, the coverage texture is not exactly tied to the terrain vertices. If your terrain is 513x513, then ETSM will use 512x512 coverage textures. But size-wise it's pretty much the same, so the impact of the brush size is comparable between terrain deforming (which affects vertices) and painting.

asmo
Greenskin
Posts: 112
Joined: Thu Nov 16, 2006 8:37 pm
Location: Sweden
Contact:
KungFooMasta wrote: ..
I don't know how to do this, but I see it being done in this screenshot of the netherforce editor:...
KungFooMasta
This is a shot from our graph for pathfinding and has nothing todo with the terrain (well, as the terrain physically forces the path to follow it, you may argue that is has).

@CABAListic
Greate work! Nice to see a new terrain scenemanager, it's more then needed I believe. (:

KungFooMasta
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:
So the brown lines have nothing to do with the terrain vertices?

asmo
Greenskin
Posts: 112
Joined: Thu Nov 16, 2006 8:37 pm
Location: Sweden
Contact:
KungFooMasta wrote:So the brown lines have nothing to do with the terrain vertices?
Correct. The red lines are pathes and the pyramids are nodes in our pathfinding graph. Our physic engine creates it's own height information (using only the same heightmap), so the vertices and the graph has nothing to do with each other apart from being generated from the same heightmap.

EDIT:
As to your feature request; you can just add another pass to the terrain material that is wireframe.

syedhs
Posts: 2702
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 47
KungFooMasta wrote: I don't know how to do this, but I see it being done in this screenshot of the netherforce editor:

http://www.netherforce.com/images/editor_path.jpg

Does anybody know how this can be done? Can we add this to ETSM?

KungFooMasta
If I get your request correctly, it is for the AI pathfinding isn't it? One simple way to do it is to paint (of course using texture splatting) a new path meant for pathfinding using different texture and have your s/w read this texture file for lookup purposes. Of course this texture will not get drawn in the terrain.

KungFooMasta
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:
Actually I was wondering how to see the terrain edges (WIREFRAME) while still rendering the terrain texture (SOLID).

I think the answer lies with adding another pass that is WIREFRAME, has some depth bias, and has an ambient color that stands out from the terrain.

Tonight I will play with the ETSM demo and see if I can get terrain edges to appear. If it works I'll post up the code and maybe we can add it to the current ETSM code base.

KungFooMasta

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

Wireframe on top of Terrain!

Here is the code, I hope you add it into ETSM code base (after you touch it up to meet your standards. )

ETSceneManager.h:

Code: Select all

``````public:
/** Render the terrain wireframe over the terrain texture. */
void showWireFrame(bool show);
...
private:
...
bool mWireFrameShown;
unsigned int mWireFramePassIndex;
``````
ETSceneManager.cpp:

Code: Select all

``````...
mWireFrameShown(0),
mWireFramePassIndex(0)
...
void ETSceneManager::showWireFrame(bool show)
{
Ogre::MaterialPtr mp = const_cast<const Ogre::MaterialPtr&>(mMaterialHandler->getMaterial());

if (show && !mWireFrameShown)
{
Ogre::Pass* p = mp->getBestTechnique()->createPass();
mWireFramePassIndex = p->getIndex();
p->setDepthBias(2.0);
p->setPolygonMode(Ogre::PolygonMode::PM_WIREFRAME);
p->setAmbient(0,1,0);

mWireFrameShown = true;
}
else if(!show && mWireFrameShown)
{
mp->getBestTechnique()->removePass(mWireFramePassIndex);

mWireFrameShown = false;
}
}
...
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 == "ShowWireFrame")
{
showWireFrame(*static_cast<bool*>(const_cast<void*>(value)));
}
...
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 == "GetWireFrameShown")
{
bool* shown = static_cast<bool*>(value);
*shown = mWireFrameShown;
}
...
``````
And modifications to the demo:

Code: Select all

``````...
case OIS::KC_SPACE:
mWireFrameShown = !(mWireFrameShown);
mSceneMgr->setOption("ShowWireFrame",&mWireFrameShown);
return true;
...
``````
So regarding the Paintbrush size, it seems the size may be dependent on the terrain size?

The following screenshots show 2 spots painted at 1st (2000,300,2000) and then (4000,300,4000):

Does it look like the portion of the terrain that is painted in the second screenshot appear bigger than the first? They both have the same TextureRepeatX and TextureRepeatZ, so the second one would have the texture more stretched. I haven't ran tests against this, just wondering if there is anything wrong, or I'm just making things up.

Hope people like the wireframe capability!

KungFooMasta

CABAListic
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:
As I said, the brush size maps to terrain vertices. If the two screenshots both have the same amount of terrain vertices (i. e. equal heightmap size), then yes, painting with the same brush size will affect a larger visible area on the second screenshot, because the vertices have a larger scale...

KungFooMasta
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:
Alright, I got it now, finally sunk in.

Are you going to add in the code for future users who might want to use this feature?

KungFooMasta

CABAListic
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:
Maybe I'll include it in the next release, but that won't come any time soon, I'm afraid. I have other things with higher priority to attend to

asmo
Greenskin
Posts: 112
Joined: Thu Nov 16, 2006 8:37 pm
Location: Sweden
Contact:
I would advice you, CABAListic, to try to keep what can be done outside the scenemanager outside it. Look what happend to PLSM2, it tries to be everything. Do one thing, and do it damn well (:

CABAListic
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:
You are right, of course. I thought about that, too, and I guess it would even make sense to remove the entire material handling from the scene manager. That way, you could do (editable) splatting, wireframing or even just plain simple materials like standard TSM approach without needing direct support from ETSM.
But that's just an idea for the moment. As I said, I want to focus on other things first before I get back to the next version of ETSM

KungFooMasta
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:
I don't understand the reasoning there. As the "Editable Terrain Scene Manager", it should include functionality for editting the terrain. Anything related to edditing terrain (features) should be taken care of via the Scene Manager. Otherwise, you will have a scene manager that is capable of deforming and splatting, but forces the user to do everything himself/herself. Very flexible, with no features.

I'm not sure it should be looked down upon when people want to contribute things to the ETSM. My code is hardly complex or bloats anything. So far I have only provided a method to clear the terrain, and show the terrain wireframe.

I guess if you want to discourage people from contributing what they think would be a good feature you're heading in the right direction.

KungFooMasta

CABAListic
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:
Nah, you misunderstand the point. The first and foremost responsibility of the ETSM is to render terrain and provide the ability to deform it - which it does. And equally so the editable splatting is a core feature, but: it doesn't need to be implemented into the scene manager itself. Everything that currently is the ETMaterialHandler could be placed into an external library because it does not need to know anything about the terrain.

The consequence is that the scene manager no longer handles the material used for the terrain. And that's a bonus because it makes everything so much more flexible. I'm already at a point where the current dynamic material provided by ETSM no longer serves my purposes. I could extend it, of course, but that would be overkill for anyone who does NOT need it Having it external makes it easier to adjust. Equally, your wireframe piece could then easily be placed as an added component to the external material handler (from a glance over it, it doesn't seem to need access to the terrain itself).

This approach doesn't make using it more complicated except that you'd have to include another header file and another lib. You'd simply initialise the material handler on your own, pass its material to the scene manager, and then you could direct any splatting edit to the material handler instead of to the scene manager.

KungFooMasta
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:
Wouldn't that be the same as saying "not everybody will be using the Entity Class, so I will make it into a plugin for the people that do want to use it"?

The material is created just for the terrain, and cleaned up when the terrain is cleaned up. The material itself may not need to know where the vertices are and other low level details, but it is tied to the terrain. Take the Entity class and apply the same philosophy, would you make an external material handler for it? (Maybe the complexity of the material handler is what requires this change of domain?)