Ogre Forums

Very strange. I thought every "detectable object" would return a RayQueryResultEntry as worldFragment of movableObject.

That is exactly what I thought, but I can't get the IsoSurfaceRenderables(which inherit MovableObject) to be picked up by a raycast. Almost as though there's a mask on the query.

Something I just noticed is that the memory address of the worldFragment is always changing at every raycast. This seems to not be normal. Why would the memory address change with the same raycast to the same tile?

G'day drwbns,

drwbns wrote:Something I just noticed is that the memory address of the worldFragment is always changing at every raycast. This seems to not be normal. Why would the memory address change with the same raycast to the same tile?

If you are modifying the terrain using a ray cast to pick the spot to modify, then with the nature of the Marching Cubes algorithm, the mesh has to be rebuilt wholess bowless for that page on every little change, hence the term "Marching Cubes" because the triangle list has to change, so there fore a new memory block. Well that's what I gather anyway, but having not looked at the code, I can't really say just yet.

Alex

I should have said that this is without any modification to the terrain, just simple raycasts to check for cursor/ball mesh placement. I found I was able to detect the SimpleRenderable as a MovableObject but it's at a distance of 0.0 so I'm still not sure as to how to get it's actual position. I'm looking into raycasting to the polygon level and possible converting it into a mesh.

So I got this somewhat working with raycasts. I ended up duplicating the isosurface on every terrain change. I'm getting an access violation that I can't quite track down. call stack ends up here - somehow my OverhangTerrainSceneManager is ending up null...

I regret so see that you ended up to "null" after all your efforts ...

Well, it works - just barely. As long as you only draw on one tile - it's fine . But I'm actually in the process of trying to statically linking the plugin. I don't suppose you've tried to, have you? It's really strange the way it's not compiling - the compiler is saying -
@ this line -
It's really bizarre, because it's defined just fine, all headers and source files are in the project. And I can even right click and go to definition just fine for mOptions. any thoughts on that?

I never tried the OverhangTSM, because I'm a Mogre (C#) user and can't use it without a wrapper or ported code.
This topic I just follow for interest.

I'm new to OGRE, but I'm planning to make a game with a similar world / terrain system to MineCraft, although I'll be using smooth geometry instead of blocks. I looked for a voxel + marching cubes implementation, and this one seems the best implementation to me. I got the tutorial framework to compile, and will try to compile the source code for this next. I have a few questions however.

First one is if this scene manager is still being continued. I got the source and demo from the first post but that's from 2007. This is really awesome and well done and I hope it will still be maintained. My second curiosity is what license this is under. Is it MIT like OGRE or GPL / PD / something else? I can't use it until I know, as I might base my project entirely off it once I decide what I wanna do. Please let me know about these things, and congratulations for the great work!

[EDIT] I tried to compile this with VS2010 over the OGRE sdk for that version. I get a ton of warnings, and also a few compile errors related to how dll's are linked. Since I'm a beginner in C++ I can't fix them manually, nor could find an automated converter. Would be nice and highly appreciated if someone could fix this and update. Here is my build log: http://pastebin.com/dbHSFVfp

Hi MirceaKitsune,

Welcome to the Ogre world.

Yes, the OverhangTerrainSceneManager looks great.
Unfortunately the development stopped at the level of a "technical demonstration".
The code shows how height map can be modified like a mesh, but it's not optimised.
So edited terrain will cause lower frame rates. (Maybe because of a missing LOD management?? I'm not shure.)
If I remember right, the creator stopped his development, but (unfortunately) nobody continued it.

Technical:
The OverhangTSM is an extended version of the Terrain Scene Manager.
It's an old terrain solution of Ogre. It was fine, but not it's replaced by the Ogre Terrain Component. The Terrain Scene Manager was removed in Ogre 1.8.
Theoretically the OverhangTSM can work in Ogre 1.8, too.
But as you see, the code needs some updates.

I'm not shure - maybe someone applied some updates (to Ogre 1.7?). Search for it in the latest posts of this topic. Some months ago somebody created a public repository for that.
If you manage to make further updates (solve compiler problems), it would be nice if you publish the updated code. The best would be to ask the repository creator for write access. This is better than a download link or an additionally repository.

For a game like Mindcraft the Ogre class ManualObject is very nice.
By this it's easy to create custom objects by code. (Additionally it can be converted to a mesh and saved as mesh file if needed)

Just check out GSoC for this year.
That's going to blow the socks out of OTS.

Thank you for the welcome and info. I heard about OverhangTSM but didn't find a demo or topic about it. What's GSoC going to be like? Anyway, here's a thread I made which is more specific on what I'm looking for: http://www.ogre3d.org/forums/viewtopic.php?f=1&t=69951

jacmoe wrote:Just check out GSoC for this year.
That's going to blow the socks out of OTS.

Interesting GSoC topics again.

MirceaKitsune, here is the link for "Volume Rendering with LOD aimed at Terrain"
http://www.ogre3d.org/forums/viewtopic. ... 41#p453641

But it will take about a half year until it's (hopefully) finished.

Thank you. I can wait half an year I guess... will hopefully get better at C++ till then for a good start.

I stopped working on it more or less out of frustration trying to understand why it was designed the way it was. I moved onto using PolyVox to try to get some good results which is running a lot smoother. I may or may not work on OTSM again.

drwbns wrote:I found I was able to detect the SimpleRenderable as a MovableObject but it's at a distance of 0.0 so I'm still not sure as to how to get it's actual position. I'm looking into raycasting to the polygon level and possible converting it into a mesh.

If you (or someone else) are interested to continue on OTSM, you can have a look to my completely re-written polygon raycasting code.

Sources are here (C#):
http://www.ogre3d.org/forums/viewtopic. ... 83#p446083

Description is here:
http://www.ogre3d.org/forums/viewtopic. ... 51#p448551

It alco contains the method TerrainRayCorrection() to receive much more precise distance results for RayQueries to terrain.
Note: This is only needed for TerrainSceneManager and it's forks like OverhangTSM. The returned terrain distance is always rounded up. (e.g. if real distance is 7.2, the TSM returns 8.0 instead.) Exception: Only vertical rays return precise distance.
The new Terrain Component is precise by default.

drwbns wrote:I stopped working on it more or less out of frustration trying to understand why it was designed the way it was.

I can feel with you. Undocumented sources can be hard to understand and never ending compiler errors are realy frustrating.
At least it would be good if the author of OTSM gives us the link of the "paper", where he read the basics how terrain modification can be done. So this could be useful to understand/continue on OTSM or to embed such functionality to the new Terrain Component.

Nevertheless it would be nice, if you upload your latest state to the repository. (Do you know which I mean?)
This could be useful if somebody else wants to continue the work.

drwbns wrote:I moved onto using PolyVox to try to get some good results which is running a lot smoother.

Is PolyVox based on Ogre or an other 3D library?
Can you give us a link, please?

Beauty: Voxeliens is made with Polyvox and Ogre - look in Showcase, one of the most recent posts.

Very interesting.

Here is the link:
http://www.ogre3d.org/forums/viewtopic.php?f=11&t=68078

Oh, the link was only to the "end product" of the voxel library.
Here is the "real" voxel topic: Fully Destructible Levels

Hi Ogreforums community, this is my first post

I've been learning me some Ogre the last couple weeks. Neat stuff! So for my project I wanted overhangs, cliffs, caves etc, so here I am. I finally got this OverhangTerrain compiled with Ogre 1.8.1 - wow what a cool concept. Metaballs ftw. I guess my question for the community is where are we at with this thing? Has anyone implemented LOD yet? Anyone fixed the seam lines not lining up?

I've implemented a save/load of the edits easily enough, just track edits to a flat file of positions/radius/inoutbool and then replay them on file load. I found it helped a lot to mod the library src a little so it would defer updates to the metaball terrain fragment until all the edits had been added to its metaobject structure. Load times went from 30 seconds on a 3ghz loading a terrain with 500 edits to about 2 seconds for the same. Definitely worth it.

BTW to the original author of this overhang terrain lib, Way to go! Wow what a neat way to approach a tough problem. Thank you so much for all your hard work.

Beauty thanks for posting your CMake project, I tried to use it but could not get DLL to compile. Maybe I'm doing it wrong? So far my only luck using OverhangTerrain has been with static linked lib, multi-threaded dll. Compiles to 100+ meg lib but it works.

I'm attaching my visual studio 2010 project to compile the lib (without any of my edits, they dont seem done yet). Maybe it'll help someone else out there struggling, or maybe someone can help me get my project setup to build dll, which i would prefer.

Hey here's the editor sample with as a VS2010 solution as well. I think i had to make some minor changes to the code somewhere, ms_Singleton -> msSingleton etc etc. Should compile fine with Ogre 1.8.1

I think the VolumeComponent is going to be far superior in it's design, so I would wait for it to be finished rather than waste time with otsm.