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

KungFooMasta · Post by **KungFooMasta** » Thu Dec 27, 2007 7:16 pm

Wow, don't know why that function didn't stick out the first time I read it. It seems that after digging into a few functions my eyes start to glaze over...

Ok so I have some questions, starting small..

It looks like the terrain has one DataGrid component, and doesn't need any more, right?

This class stores a list of "Data grid values" as well as "Vertex positions of the grid points". How are these two related?

What are grid values?

Would "Vertex positions of the grid values" be correct, or are they different?

What does the grid represent?

A MetaHeightmap is a MetaObject. How does this map work into terrain generation? What happens when the MetaHeightmap updates the data grid?

My first goal is to display terrain and initialize the Library without any overhangs. Would the following code be sufficient?

Code: Select all

	static isot::IsoSurfaceTerrainBuilder isC(xDim, yDim, zDim, QUAD_SIZE, mTerrainPosition,isot::IsoSurfaceTerrainBuilder::GEN_NORMALS);
	isC.clearMetaObjects();
	if(blobCounter < 1)
		isC.setHeightfieldCallback(&myClass::myGetHeightFunction);
	isC.setPosition(mTerrainPosition);

Basically ETM will have created the terrain, and I will have created the IsoSurfaceTerrainBuilder object, but it doesn't do anything. I still don't see how creating MetaBalls and adding them in will change how ETM renders the terrain..

Also, where does this number come from?

Code: Select all

#define QUAD_SIZE 2.9296875f

Sorry for all the questions, let me know if it gets irritating.

Temp76 · Post by **Temp76** » Fri Dec 28, 2007 5:39 pm

i'v been reading abit about Chunked LOD the last few days and .chu file streaming seems this would almost be perfect at runtime for this, hold the overhang tarrain data in the .chu and stream it in as you need it at error 1 but say error level 2 or 3 (player is far away or tile is out of sight) load normal tarrain or none at all, it should also fix texture mixing as you can steam per tile and also saving UV's? good part is adding the overhangs and caves shouldn't cost you much and you can have as many as you want

beaugard · Post by **beaugard** » Sat Dec 29, 2007 9:45 pm

This class stores a list of "Data grid values" as well as "Vertex positions of the grid points". How are these two related?

The DataGrid is the spatial representation that the marching cubes algorithm uses. You can probably get a better idea about all this by reading about it. The Vertex positions are the positions of grid points (relative the center of the grid) these are constant for the lifetime of the grid. The grid values are rewritten every time a new isosurface is created - these store the "field strength" at the grid points.

What happens when the MetaHeightmap updates the data grid?

Check MetaHeightmap::updateDataGrid().

I still don't see how creating MetaBalls and adding them in will change how ETM renders the terrain..

It won't. You will have to hide the parts that are affected by metaballs. This is what all the messy code in the OverhangTerrain SM does for the TSM.

Also, where does this number come from?

Code:
#define QUAD_SIZE 2,9296875f

That's a hack, just for the demo. It's 1500/512... guess why!

jingjie · Post by **jingjie** » Sun Dec 30, 2007 12:40 pm

Dear beaugard:
In the future work of Overhang Terrain Scene Manager , would you support to develop Overhang Terrain Zone of the Portal Connected Zone Scene Manager(PCZSM)? (http://www.ogre3d.org/phpBB2/viewtopic.php?t=6658)

beaugard · Post by **beaugard** » Sun Dec 30, 2007 1:19 pm

Probably not, but if someone else wants to do this, it's should be easy. - the OTM shares a lot of code with the TSM, which is already ported.

@Temp76:
I think I understand more-or-less what you want to do, but there might be a problem with this approach. If you just use MetaBalls for caves it's ok, but if (an artist, say) builds bigger structures on top of the terrain, this should be reflected at lower LODs, too. This is why instead I am opting for building a heightmap shell for lower LODs instead.

Temp76 · Post by **Temp76** » Mon Dec 31, 2007 11:10 am

True, it should be fine with large stuctures to and you can ues all levels of details if you want the thing i liked the most is holding the UV's and you can edit to file, well i'll soon fined out i'v been working on getting chunked lod going with ogre should be going in the next few days, Thanks

noche · Post by **noche** » Wed Apr 09, 2008 2:42 pm

Hello

I really like the approach you use for sculpting terrain

I've been looking your code cause I'd like to use it just to manage metaball without a terrain. I don't clearly see where I can cut the code for this.
My understanding for now is that only the folowing classes are necessary to manage metaballs (and could be placed in a separate "metaball library")

DataGrid -> the representation of the grid use in the marching cube algorithm
DynamicRenderable -> brings the abilities to render dynamic objects into ogre
IsoSurfaceRenderable -> brings the abilities to render metaballs into ogre
IsoSurfaceBuilder -> build the surface using marching cube
IsoSurfaceBuilderTables -> tables used by marching cube
MetaObject -> a base class of all the object that will be considered during the marching cube
MetaBall -> the concrete class the represent a metaball.

In my point of view, a metaball library should provide (at least) a way to :
- Create a MetaBallManager entity, that can be attached to a SceneNode
- Add multiple MetaBalls into a MetaBallManager
- Change the position and radius of a MetaBall
- Remove a MetaBall
- Ask the MetaBallManager to re-generate the mesh (if we added, destroyed, changed a metaball)
- Define the precision of the MetaBallManager

Would you have any advice to reuse your code to do this ?
Thanks.

jingjie · Post by **jingjie** » Wed Apr 23, 2008 11:06 am

noche wrote: In my point of view, a metaball library should provide (at least) a way to :
- Create a MetaBallManager entity, that can be attached to a SceneNode
- Add multiple MetaBalls into a MetaBallManager
- Change the position and radius of a MetaBall
- Remove a MetaBall
- Ask the MetaBallManager to re-generate the mesh (if we added, destroyed, changed a metaball)
- Define the precision of the MetaBallManager

Would you have any advice to reuse your code to do this ?
Thanks.

the metaball is a special case in general solution of iso-surface.
a general iso-surface library must be some main functions.
1. Needs iso-surface mesh generation by GPU and Parallel Marching Cube algorithm.
http://www.gunnar-johansson.se/index.ph ... &Itemid=31
2. Needs iso-surface rendering of various implicit functions.
3. Needs dynamic editable and constructive operators of various iso-surface mesh( like Constructive Solid Geometry Operators)
http://en.wikipedia.org/wiki/Constructi ... d_geometry

jingjie · Post by **jingjie** » Thu Apr 24, 2008 5:32 am

noche wrote:Hello
Would you have any advice to reuse your code to do this ?
Thanks.

its metaball rendering is reference on this:
http://www.ogre3d.org/phpBB2/viewtopic.php?p=68286

isosurfaces demo
http://dword.dk/public/ogre/isosurfaces.zip

beaugard · Post by **beaugard** » Thu Apr 24, 2008 9:24 am

Yes, those last links are the ones I would have posted, thanks jingjie. Sorry to ignore you for so long, btw. I've been "away" for a while - two paper submissions (one still not finished) + flu + sick child...

In case you're interested, my own project uses only metaballs and no landscape. What I am trying to do is to create an infinite, completely dynamic, cave using paging - on-the-fly generation with caching of nearby IsoSurfaces. Also I integrated physics (Bullet engine) and all geometry and collision geometry is built by worker threads. So far everything is working very smoothly. One major task that remains is to use pools of objects for the geometry - now they are just new/deleted which will give terrible memory fragmentation, I'm sure. I am hoping to put together some little game to showcase the technology, but as you can understand everything is working very slowly right now...

jingjie · Post by **jingjie** » Mon Apr 28, 2008 4:54 am

beaugard wrote: In case you're interested, my own project uses only metaballs and no landscape. What I am trying to do is to create an infinite, completely dynamic, cave using paging - on-the-fly generation with caching of nearby IsoSurfaces.

Wow, it sounds amazing project and I am interested in isoSurfaces generation to apply to editable overhange terrain system that create textures and triangles of isoSurface dynamically in memory and allows you to edit them.
But is isoSurface how to edit textures dynamically like ETM?

Master beaugard , Do you have any idea for this problem ?

Thanks.

beaugard · Post by **beaugard** » Mon Apr 28, 2008 9:10 am

Adding texture coordinates is a huge problem that I completely disregard. Instead I just "fake" it using the vertices xyz position and triplanar texturing - works for simple terrain, but doesn't really allow much artist input (the way I do it, anyway). In fact I am not sure it is at all possible to auto-generate texture coordinates and avoid seams. In the "cave" chapter of HL episode two Valve used the same approach as I do instead of regular UV texturing.

Maybe "Master PolyVox" has some better ideas about this

.

PolyVox · Post by **PolyVox** » Mon Apr 28, 2008 10:23 pm

beaugard wrote:Maybe "Master PolyVox" has some better ideas about this .

Ah, that's my cue

Well I am also still using triplanar texturing in my project. I think it works pretty well for natural looking textures (so it's a good fit for your project) but doesn't really work for man made texture such as bricks.

I'm also wondering how easy it is to perform bump/relief/displacement mapping. What the effect of triplanar texturing on the heightfield? I haven't thought about it a lot yet but I think it gets tricky...

I also chased the guy about his application for generating solid textures from 2D ones, as this could be very useful. I'm talking about this:

http://www.johanneskopf.de/publications/solid/index.php

He told me he hadn't had time to tidy up the source code and didn't know if he would get around to it. I said it really didn't matter and I would be interested in it in any state, but I haven't heard back again... Maybe he'll release it if more people chase him!

beaugard wrote:In the "cave" chapter of HL episode two Valve used the same approach as I do instead of regular UV texturing.

Huh, I didn't know that. Now I'll have to go back and play Episode 2 again to see...

noek · Post by **noek** » Wed May 07, 2008 5:59 am

First off, awesome stuff beaugard. With minimal work I'm tunneling and building bridges in a linux build, too much fun. I've ran into a couple of issues with stitching and tiles disappearing/reappearing as terrain is modified, but it sounds like that might be more of an issue with the original TM code.

Awhile back you talked about an IsoSurfaceTerrain library, is that still in the works at all, or at least shelved somewhere safe in an alpha state for those of us who might be interested ?

beaugard · Post by **beaugard** » Wed May 07, 2008 11:59 am

Awhile back you talked about an IsoSurfaceTerrain library, is that still in the works at all, or at least shelved somewhere safe in an alpha state for those of us who might be interested ?

I am not working on it, but it is somewhere safe in pre-alpha state, and I'd be happy to mail it to you if you're interested in working on it. Basically, I got rid of all the TSM code and used a callback for getHeight instead. This reduces the complexity of the code (still messy, though) and would allow you to integrate the library into different (terrain) scene managers.

noek · Post by **noek** » Fri May 09, 2008 4:28 pm

Awesome, I sent you a PM with my email address. Thanks!

beaugard · Post by **beaugard** » Fri May 09, 2008 5:34 pm

Yes, I got it. Just haven't had time to find the code and send you yet. In the weekend, surely.

beaugard · Post by **beaugard** » Sat May 17, 2008 1:59 pm

Noek, I finally sent you the source. Sorry for the delay - things have been a bit crazy around here...

Daerst · Post by **Daerst** » Sun May 25, 2008 10:01 pm

What would be the best way to use this overhang terrain with a physics engine?

FlyingIsFun1217 · Post by **FlyingIsFun1217** » Mon May 26, 2008 2:24 am

Daerst wrote:What would be the best way to use this overhang terrain with a physics engine?

By integrating the physics

Sorry, I had too

FlyingIsFun1217

beaugard · Post by **beaugard** » Mon May 26, 2008 8:55 am

What would be the best way to use this overhang terrain with a physics engine?

I'd say use a static trimesh shape and maybe offload construction to a worker thread - that's what I am doing.

There are probably more efficient ways than vanilla trimesh. Bullet has some (possibly experimental) partial aabb refitting, I think. Also, you should be able to almost remove the aabb-tree building by using the fact that all triangles in a mesh generated by marching cubes are already confined into a cell of a regular grid. This could be used as a mid-phase for bullet collision detection - aabb of terrain tile is broad-phase, collision with cells mid-phase (maybe using some hash-space approach), triangles narrow-phase. I had plans to implement this but then I realized that constructing the aabb tree was pretty fast anyhow. Still, if you try to implement it I'd be interested in the result

.

PolyVox · Post by **PolyVox** » Mon May 26, 2008 5:59 pm

beaugard wrote:...Also, you should be able to almost remove the aabb-tree building by using the fact that all triangles in a mesh generated by marching cubes are already confined into a cell of a regular grid ... I had plans to implement this but then I realized that constructing the aabb tree was pretty fast anyhow...

I am in the same position (as always

) and I had a conversation with Erwin about this on the Bullet forums. Have a look here:

http://www.bulletphysics.com/Bullet/php ... f=9&t=2050

I got it partly working but have been distracted. And as you say the construction of the AABB tree is pretty fast. I think there are more gain to be got from using a lower detail mesh for the physics.

beaugard · Post by **beaugard** » Mon May 26, 2008 8:36 pm

Yes, I think we are doing more or less the same thing (just recreate the btBvhTriangleMeshShape each time something changes). IIRC, I don't create a RigidBody for the shape. Also, I offload the btBvhTriangleMeshShape creation to a worker thread.

What I suggested was something else, though. Since a mesh created with marching cubes (without mesh decimation) have vertices that each fit into a grid cell, you could use this for midphase collision detection. I this way the aabb-tree for the vertices in the mesh would be replaced with a spatial hash. The hash could be filled inside the marching cubes code, so there would be very little overhead. Of course, the bounding boxes would now fit the verts a little bit worse, so there would be more missed triangle intersection tests. Basically, you'd swap running efficiency with creation efficiency.

db123 · Post by **db123** » Tue Jun 10, 2008 10:16 am

If I can save it as a .cfg file,it may be more good!!

beaugard · Post by **beaugard** » Tue Jun 10, 2008 11:14 am

You mean to save/load the positions and strengths of the metaobjects? Feel free to add it - should be trivial.

Please note that the OTM is not intended as a stable terrain solution for your game, though. I could have added some features like what you mention easily but but I will never have time to make it stable enough, so I prefer to keep it like this, more like a demo. If anyone wants to develop it further, you have my blessing.

Ogre Forums

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

IsoSurfaceTerrain library ?