Overhang Terrain Scene Manager - source released (page 5).

[Temp76]

Great news, i love this project i have a real thing for overhangs lol

[KungFooMasta]

beaugard:

Some ideas and/or requests for your library, if you care to listen.

1. I like the Ogre method of creating objects and then attaching them to SceneNodes. (ie lights, entities, cameras, etc.) Not sure if this is possible with OTM, but it would definately fit right in with the Ogre design of adding renderables into the scene. (Terrain isn't visible until you attach it to some scene node)

2. I believe if you inherit from Ogre::Movable, you can make use of the standard scene ray casting to see if the terrain is hit. It wouldn't be accurate at all, so its not incredibly useful, but it would be able to distinguish from clicking the terrain and clicking a ninja on the terrain.

3. Giving convenient access to vertices and indices of the terrain. You know the best way to include this in the design, and allow for easy integration with physics libs.

I'm not trying to add to your plate, just giving out some possibly good ideas.

[beaugard]

I won't make any improvements to the OTM, because to make it a viable alternative would take way too much time. Instead let's work together to make a useful isoSurfaceTerrain library, that can be used in any SM. I already have working code, will release soon. Maybe it would be worth to put it on sourceforge?

Modularizing like this would solve all three requests...

[KungFooMasta]

That's actually what I meant! (My "OTM" is your "IsoSurfaceTerrain")

I've been digging into PhysX over the past 2 days, and haven't successfully gotten ETM's terrain to become a PhysX actor. I would have thought working with heightmap images would be the easy route.

On the flip side, I have reference code on how to create a PhysX actor from an Ogre::Mesh object. And with all the benefits of OTM, and use of mesh data... it would work out really nicely for me.

It would be sweet if we could simulate design similar to the Ogre::ManualObject class, regarding use of "begin" and "end". Basically the Terrain would be a mesh except in edit state. (Although I'm not familliar with the code, what I'm suggesting could be ridiculously difficult to do)

You should put it up on source forge, so we can work together on this IsoSurfaceTerrain library.

[KungFooMasta]

beaugard, you went silent!

I'm working with PhysX in my team's project, integrating PhysX actors (cube, sphere, plane, capsule, convex, etc.) into our scene. Getting IST to load, even as a flat plane, should be a good introduction for me. You said Scene Manager functionality has been removed, right? This would be desired, anyway.

[beaugard]

Yes, sorry about falling silent, I am not so good with forum communication... hm, maybe I'm not good with communication, period

The reason is that while cleaning up the IsoSurfaceTerrain library project, I got inspired and started to write routines for dividing the isosurface into a heightmap component (efficient) and one 3d component. Also I wrote code to generate a "heightmap-hull" for high LOD. So the code is not in any state to start a sourceforge project just yet.

If you want to have a preview I could just mail you the lib in the current state (I can comment out enough to make it compile). It should be easier to understand than the OTM, anyway.

[Falagard]

Sounds cool, can you clarify what you mean by breaking it up into a heightmap component and 3d component, and what a heightmap hull is?

I can guess that a heightmap hull is a heightmap representation of the overhang version of the terrain which can be used at a distance instead of the overhang version, amirite?

[KungFooMasta]

Maybe its something like multiple heightmaps where terrain overlaps? I haven't been able to get a feel for performance regarding heightmap shapes vs trimesh shapes. Either way, my game will need to update the collision shape a lot, as real time deformation is a feature.

Sending you a PM, I'd like to get familiar with your code.

[beaugard]

.... instead of the overhang version, amirite?

Yes, the idea is that far away, you can swap the true 3d mesh for a heightmap. It even comes with a stride parameter, so you can get the low-res version directly! Implemented but not tested.

can you clarify what you mean by breaking it up into a heightmap component and 3d component

Here the idea is to keep the heightmap representation for all quads that are not broken by overhangs and only generate the overhang mesh for the parts where it is truly needed. So you end up with a terrain tile broken up into two objects - one is parts of the "heightmap hull", the other one is the overhang parts. For the hull it would really just be an alternative index buffer...

This would be especially useful for caves, where the end result would be the heightmap (with possibly slightly modified heights) + a cave mesh. Also, I imagine artists might want to use blobs to scupt terrain that are not overhangs - with this feature they would automatically be converted back to heightmaps (with modified heights). Anyway, it will probably increase the generation time quite a lot, so it will be completely optional. I started this one, and I have an idea on the algorithm, but probably it's not as easy as I think... we'll see.

[Falagard]

Yeah, that's what I thought you meant about both things

Very cool, interested to see what you come up with.

In the meantime I may start playing around with your old source code, since I do want integration between a terrain manager and overhang system.

I'd really like to see if I can have a mix between the editable terrain manager and the overhang terrain manager, like I mentioned before. This would mean the ability to edit heightmapped terrain, and overhangs, within the same editor.

[beaugard]

The best thing would be if the TSM/Editable TSM/whatever SM could just give the ability to swap out tiles for any object... maybe subclassed from a "tile" object or whatever. This would allow easy integration of overhang tiles as well as regular meshes, and one could implement raycasting, etc, as one wants. This would require quite a bit of thought - a lot of low level stuff has to be settable by the user even on normal tiles. For example it would be nice to allow the tiles to react on LOD-change signals, etc, instead of assuming a certain behaviour (for example, to turn off vertex morph for the verts that participate in stitching).

My approach of having a "negotiator" object (terrainTile) which keeps pointers to both the heightmap and the isosurface is very hacky, I think. Subclassing seems better (I chose it because I was afraid some part of the system would keep pointers to the tiles which would be invalidated if I turned a haightmap into an isosurface).

Whichever approach you take, I'm sure the library will be easy to integrate into it.

Very cool, interested to see what you come up with.

yeah, ehm... keep your fingers crossed .

[KungFooMasta]

Instead of mix matching heightmap with mesh objects, why not make each tile into a mesh? This is more useful that one giant mesh, and less confusing than mixing heightmap and mesh pieces together. Using broadphase collision, simple bounding box queries can be used to rule out collisions with objects. Also, if you take this hybrid approach, how will a heightmap represent a chunk of terrain that is really a 3d mesh object? Usually the lowest value is the lowest height, and vice versa, but it looks like you'd need some kind of special value for areas not occupied by heightmap generated terrain? Is the main desire for heightmap the use of LOD?

Regarding raycasting, it shouldn't be a major concern, especially if it constrains functionality. Most of us are using a physics lib, and you can do physics style ray queries instead of the default scene queries.

[Praetor]

Yes, LOD on terrain is really important.

[Falagard]

Yes, LOD on terrain is really important.

Actually, it depends on requirements
Personally I've finally resigned myself to the fact that as an indy/hobbyist programmer with limited time and budget I'm not going to be able to create the completely free roaming game that I want and instead am going to have to have zones.

[KungFooMasta]

My project involves smaller RTS style maps, so LOD isn't very important to me. Also, isn't there mesh LOD?

Back to ray casting, I believe there is some code on the wiki to get ray casting down to the polygon level.

Converting tiles into Ogre::Mesh or Ogre::SubMesh objects would be really useful in a lot of ways, including use of paging mesh tiles, serializing to .mesh, maybe use of ogre materials per tile, etc.

[beaugard]

Instead of mix matching heightmap with mesh objects, why not make each tile into a mesh?

It would be more a bit more difficult to implement (I think) and it would exclude stitching at the edges of the tile (well, make it a lot more difficult to implement, at least).

Actually, the hull can use the vertex info from the original heightmap, with a different index buffer. Then you can simply have a flag to tell if none of the verts on a side are from the mesh, and in this case you can do stitching on that side!

Also, if you take this hybrid approach, how will a heightmap represent a chunk of terrain that is really a 3d mesh object?

It wont. It will be represented by two meshes.

Regarding raycasting, it shouldn't be a major concern, especially if it constrains functionality.

That was just meant as an example of something that the Terrain SM's author might want to leave to someone implementing a custom tile. I will not care about this at all in my implementation.

@falagard:
I would actually argue that LOD is especially important for terrain (you tend to be really close and expect to see really far). And since the functionality is already there in all TSM's, why not use it. My original thought was that it'd be acceptable to constrain the tiles with overhangs (and the ones around) to max LOD, while using the normal algos for all the rest. This way you can choose - big vistas or detailed overhangs.

[beaugard]

Converting tiles into Ogre::Mesh or Ogre::SubMesh objects would be really useful in a lot of ways, including use of paging mesh tiles, serializing to .mesh, maybe use of ogre materials per tile, etc.

This is very easy to do. I think the wiki has info on how to create a mesh from vertex/index arrays. My code has the code, as well.

[Falagard]

I would actually argue that LOD is especially important for terrain (you tend to be really close and expect to see really far). And since the functionality is already there in all TSM's, why not use it. My original thought was that it'd be acceptable to constrain the tiles with overhangs (and the ones around) to max LOD, while using the normal algos for all the rest. This way you can choose - big vistas or detailed overhangs.

Um, yeah, that's why I said it was *obviously* important

Although, it also depends on the functionality required by your game, as stated by KungfooMasta who only needs a top-down view of the terrain for an RTS, and also myself, because all I'm not going to be showing a lot of terrain at the same time

[KungFooMasta]

I don't think I understand. Do you want to have a heightmap per tile?

Take the following map:

xxxxxxxxxx
xOxxxxxOxx
xxxxxOxxxx
xxOOxxxxO
XXXXXXXXX

x's represent terrain that is only vertically deformed, while the O's represent tunnels to other O's.

Would there be a height map per x, or a height map representing the entire map, with some flag or something representing the O's? Pretend you are looking at a greyscale image describing the terrain above. What would it look like?

[beaugard]

A RTS with top-down view might be an exception, yes. Although the AAA titles I've seen lately must use LOD for landscape, they display horizontal views with a very far-off horizon.

Is the main desire for heightmap the use of LOD?

Praetors answer was for this direct question, I think (answer: "Yes").

Anyhow, the library is LOD-agnostic and will remain so (until it dies and finds out whether the after-life is top-down perspective... ).

[beaugard]

I think the confusion is because I use the term "tile" to mean a renderable (mesh) of terrain. I use "quad" to mean two triangles in a square. Does it make sense?

In your example all the x's would be one mesh and all the o's (plus the actual tunnels) would be another.

[KungFooMasta]

But is the x mesh generated via heightmap?

Imagine another scenario:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xOxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxOx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

This terrain is really huge. You can't possibly see one end from the other. If each x were it's own mesh, you could use octree or paging so that only visible x meshes would be drawn. If the two connected O's were one mesh, you would have one gigantic cave mesh spanning quite a large distance. And its not likely you can stand at one cave entrance and see the exit. But as one mesh you either render all of it or none of it, right?

I still don't know how the heightmap would look..

[beaugard]

Ah, so each x is a tile - 65x65 verts, for example. We speak the same language!

The tunnel would be several meshes also - one for each tile it goes under.

EDIT: and each x would be one mesh. I am talking about turning one tile (one x) into two components. So if the O's are just a simple landscape (=heightmap) with a hole, the few verts representing the hole, plus the part of the tunnel that is under that tile would be one mesh, and the rest of the heightmap would be another.

[KungFooMasta]

I'm reading the drop you gave me, and I had some beginning questions.

The example uses the default Ogre TSM terrain and works with that. Where is the code (file) that grabs terrain data and makes use of it? Have you tried using the Gizmo object with the ETM terrain? I'm not a big fan of the TSM config files, and not being tied to the TSM gets rid of interacting with data via get/setOption methods.

Do you have an intended work flow, regarding the design of the library? For example, this is a possible idea:

setup:
1. myTerrain = new IsoSurfaceTerrain(...);
2. myGizmo = new EditorGizmo(myTerrain,...);

terrain manipulation:
myGizmo->add(...);
myGizmo->subtract(...);

collision object:
myTerrain->getTerrainWidth();
myTerrain->getTerrainDepth();
myTerrain->getTerrainHeight();
myTerrain->getTerrainHeightData();
myTerrain->getNumberOfSubMeshes();
myTerrain->getSubMesh(unsigned int index);

I've barely looked at the code, not sure where I should begin, so my ideas might not be feasible because of how things work.

[beaugard]

The library doesn't load the terrain, but instead uses a callback ( like this: getHeight(Real x, Real y) ). So you can use whichever method you want to store the data (the Heightfield class is not used for the moment) Look at IsoSurfaceProceduralInterface for how to make a terrainbuilder for a one-shot isosurface creation (inefficient, a lot on new/delete), or look at EditorGizmo::testClassInterface() for "recommended" use.

Code: Select all

void EditorGizmo::testClassInterface(bool exc) //exc == excavating (subtract)
{
	int numBalls = 20;
	Real scale = 10.f;
	static int blobCounter = -1;
	++blobCounter;


	//create an IsoSurfaceTerrainBuilder once only.
	static isot::IsoSurfaceTerrainBuilder isC(32, 32, 32, QUAD_SIZE, Vector3(.0,.0,.0), isot::IsoSurfaceTerrainBuilder::GEN_NORMALS);
	if(blobCounter < 1) //first time - we need to set the callback.
		isC.setHeightfieldCallback(&TerrainApplication::getHeightCallback);

	//prepare builder for creating a new IsoSurface.
	isC.clearMetaObjects();
	isC.setPosition(mMetaBallPosition);

	// create some random metaballs...
	for(int i = 0; i < numBalls; ++i)
	{
		Vector3 pos((frand()-0.5) * scale * 4, (frand()-0.5) * scale * 2, (frand()-0.5) * scale * 4);
		pos += mMetaBallPosition;
		isot::MetaBall *ball = new isot::MetaBall(pos, frand() * scale + scale/2, exc);
		isC.addMetaObject(ball);
	}

	//create the (named) mesh
	std::stringstream ss1;
	ss1 << "blobMesh_" << blobCounter;
	MeshPtr mesh = isC.createOgreMesh(ss1.str());
	std::stringstream ss2;

	//create an entity for the mesh, add it to scene.
	ss2 << "blobEnt_" << blobCounter;
	Entity *blobEnt = mSceneMgr->createEntity(ss2.str(), ss1.str());
	SceneNode *sceneNode = mSceneMgr->getRootSceneNode()->createChildSceneNode();
	blobEnt->setMaterialName("OverhangTerrain_simple");
	sceneNode->attachObject(blobEnt);
	sceneNode->setPosition(mMetaBallPosition);
}

...and that's really all there is to it.