Ogre Forums

Hi all,

I've taken the OverhangTerrainSceneManager (OhTSM) created by Martin Enge under my wing and began completing it including adding terrain paging support with the existing Ogre paging API. Once I've polished my revisions to an acceptable degree I plan to publish it to Google code for everyone to take advantage of.

I run into a few scenarios where I have to copy and paste huge portions of the Ogre Terrain API to get things to work since OhTSM uses a dramatically different approach to the problem of terrain. One such example is a somewhat redundant OverhangTerrainGroup class which is analogous to the TerrainGroup class which is part of Ogre. Another example includes implementing ray scene queries.

I now want to implement blend maps and realize that TerrainMaterialGenerator is tightly coupled to Ogre's Terrain class and porting this functionality to OhTSM will be very non-trivial. I will have to copy and paste the TerrainMaterialGenerator and supported / derived classes into new analogous OhTSM ones and then figure-out how to couple it with the OhTSM code-base instead of the Ogre Terrain codebase, a task that seems silly and time-consuming but I don't see any other way around it.

1. I should have asked this a lot sooner, but is anyone maintaining OverhangTerrainSceneManager?
2. What suggestions do you Ogre experts have for making blendmaps available to code bases other than the Ogre Terrain API?
3. Should I just do something simpler such as doping spiders with LSD?

Hello again,

I have been working on this project steadily and now I am trying to crack decimated iso-vertex stitching of the isosurfaces. It's very difficult and I think I'm almost there but I am still running into a problem and I would like some help. Additionally I haven't even thought about how to stitch the iso-surfaces with the height-map based terrain renderables yet.

Although the basis for OhTSM iso-surfaces differs somewhat, I have skimmed this book online and have ordered it and hope to get some ideas from it.

The problem I am having in case you are interested is that stitching along an iso-surface edge that extends into more than one adjacent iso-surface (e.g. one to the east and another to the north-east for a slanted surface) results in some ambiguity. I am using a LUT-based approach for decimating iso-vertices, and though the book warns against it I cannot tell yet specifically why.

Any takers?

I am definitely a taker!
The overhang terrain manager would have been perfect for me, if it allowed paging.
Now that you are adding paging...

I humbly request you put this into Ogitor when you're ready to do so.

Well this is definitely getting close. I have now successfully implemented PSSM+VSM+PCF shadows with one caveat: directional lights are completely unsupported, only point-lights and potentially spot lights will work. I am also virulently resisting the temptation to explore spherical-harmonics based environment lighting (such as SHEXP [1]). Now I am working on deferring rendering tasks to background threads using Ogre::WorkQueue since moving around is a little on the choppy side performing iso-surface rendering in the main thread. Other than that I don't see what's left to do for this project besides polish and performance tuning. I am considering purchasing Intel V-Tune Amplifier but it is expensive, I would appreciate any suggestions / feedback.

Some major changes made since my last post:

• The marching-cubes implementation has been completely replaced with my own implementation of Eric Lengyel's Transvoxel paper
• Hardware vertices are cached and reused quite extensively. At one point I went too far and attempted to reuse vertices for multiple resolutions. Then I realized that, although vertex positions are invariant, vertex normals aren't.
• I have also eliminated heightmap-specific renderable surfaces opting for a homogenous approach making everything an iso-surface extracted from voxels because I feared running into material/shading inconsistencies with the non-uniformity of triangles in heightmap-specific renderables. I was also unwilling to take the time to devise yet another multi-resolution stitching algorithm for stitching between heightmap renderables and isosurface renderables.
• I am using the vertex diffuse color channel to store material blending weights for textures in the first four texture units corresponding to RGBA.
• Voxel information is persistent and compressed using RLE.
• Terrain pages are serialized to disk using either the built-in method or one may implement a listener interface and provide one's own concrete terrain page serializer

A trip to Utah and Arches National Park proved to be quite an inspiration and source of fuel to persevere with this project. Highly recommended!

1. https://www.google.ca/url?sa=t&rct=j&q= ... 1473,d.cGE

Let me dig-up a screenshot or two...

Sounds like a lot of hard work. Kudos for that.

MadMartian wrote:Hardware vertices are cached and reused quite extensively. At one point I went too far and attempted to reuse vertices for multiple resolutions. Then I realized that, although vertex positions are invariant, vertex normals aren't.

What about keeping normals in a separate buffer? That would make vertices reusable again.

What did you end up doing with the OverhangTerrainGroup class?

bstone wrote:What about keeping normals in a separate buffer? That would make vertices reusable again.

Didn't know you could do that! Although I'll have to put it on the low priority list for now.

drwbns wrote:What did you end up doing with the OverhangTerrainGroup class?

It has evolved into the controller for background loading/unloading terrain pages and background terrain digging. It plugs into OGRE's paging system using the 2D paging strategy (3D might make more sense in the long-run).

Have you finished it already? Also, is it a plugin?

Nice work <3

drwbns wrote:Have you finished it already? Also, is it a plugin?

Yes it is a plugin, is it finished? yes and no. It's usable for terrain, but there is no path-finding, no collision detection, no bounding-box queries etc. The only thing like that supported is performing a ray query, and the demo will make use of ray queries to manipulate the voxels and demonstrate digging by a click of the mouse.

Matter of days before this appears on GitHub! - Once I'm finished doing inline documentation I will put this up on GitHub. Shouldn't be more than a handful of days unless life happens (which it does every now and then). I have a demo/example app that makes use of the library, I will spend a little time to polish it and bundle it with the library on GitHub.

I was unaware of this, it looks like I have been reinventing the wheel:
http://www.ogre3d.org/tikiwiki/SoC2012+ ... at+terrain

Is anyone familiar with this feature? it appears to be exactly what I intended to accomplish with OhTSM, which would mean I have reinvented the wheel. For my own project I intend on using volume rendering for absolutely everything stationary (walls, roads, railway, pillars, supports, domes, pipes, etc. and so on).

OverhangTerrainSceneManager Now on GitHub
My reboot of OverhangTerrainSceneManager is now fully disclosed with source code on GitHub at the following URL:
https://github.com/MadMartian/OhTSM

NOTE: This library really isn't ready for production, maybe for some small scale demo project, see the KNOWN ISSUES section of the README for details.

Please let me know if you have any questions.

Very cool - kudos for the effort. I'm going to try it out and report back but it looks like you already know existing issues.