Simple Paged Terrain [v2.00 Released! Page 21]

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!
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Simple Paged Terrain [v2.00 Released! Page 21]

Post by HexiDave »

To preface: there are a lot of terrain options available for Ogre. I've probably used all of them. I don't know what state PLSM2 is currently in (I know PLSM3 is in the works, though), but I know I needed a landscape system to test my core game engine features while I wait to build a new PC to work on my OgrePlanet project (debug isn't fast enough to reproduce Release mode bugs - yay for that...)

Anyways, enough rambling:
Image
Image

What you're seeing in these hideous screenshots is a simple paged terrain system. It has normals/tangents and you can produce bitangents ("binormals") in the shader like I did here. The reason why it's so god forsaken ugly is that I never did get the shader to work right so the shadowing caused by normal-mapping there is pretty ugly.

Working features:
- LOD with GeoMipMapping just like TSM/PLSM
- Inter-Page LOD - that is, the Tiles at the edge of the Page will get info from neighboring page's tile's and stitch accordingly, so no gaps.
- Uses Libnoise to generate height information at run-time and will have a lot of plug-in features as I'll list shortly.
- Easy to access the Vertex/Index buffers for tiles to feed to your physics engine.
- As stated, it's a Paged system, so it has Pages of Tiles (in my case a Page is 513 vertices wide and has 8x8 Tiles at 65 vertices each) that you can manipulate as a Page or as Tiles (i.e. you select a Page to be mostly flat using Libnoise or drop a Tile entirely in favor of a Mesh object.)

Future features:
- Floating Origin - I already have a functional system, I just need to integrate it - basically as you get too far away from the center, your vertices start jittering, this solves it by moving the camera and all the objects towards 0,0,0 and will account for this when building new Tiles.
- Completely wrap-around world - I already have a system in place, but I need to build the customization of the landscape in first as you do a Linear Interpolation on the edge Tiles/Pages with the reverse height of it's neighbor (hard to explain - will diagram later - it makes sense, though, I promise.)
- Customizable terrain creation through Libnoise's fractal synthesis including erosion algorithms and "paintable" editing where you'd actually store a heightmap that would filter in after the fractal is done.
- Run-time editing of the terrain
- And lastly something I haven't even tested, but I had thought about it:
Essentially when editing you'll have whatever bit-size to work with for heights (i.e. 0-65535 for 16 bit maps), but I think it would be possible to have a list of "extra" heightmaps you could build into that would get factored into the height of the vertex. For example: You start painting in manual height values onto your terrain and your mountain finally hits the roof of the bit value (65535 in my case), but you say "Ok, add another heightmap for this page" and it adds a fresh heightmap which you can continue adding more height values to and it builds it into the vertex, which is less limited to height value. There'd be limits to this, of course, but it shouldn't be hard to add in.


The other thing is texturing and that's easy to add to this implementation, so I'll get to that when I have time.

Once I get some of the more essential features (config files, more friendly interface, packaging, etc.) I'll release the source code. Shouldn't take me more than a few days to get a lot of that squared away.

If there's anything else you want added, post here and I'll try to tack it onto the list.

(I know it wasn't much of a Showcase, but there'll be more shots to come - I'm going to put Caelum, the Forest addon and nxOgre onto it probably tomorrow.)
Last edited by HexiDave on Mon Jun 02, 2008 5:46 pm, edited 4 times in total.
User avatar
SpannerMan
Gold Sponsor
Gold Sponsor
Posts: 446
Joined: Fri May 02, 2003 10:05 am
Location: UK

Post by SpannerMan »

This sounds great HexiDave, and good luck with the rest of those features.

"Completely wrap-around world "

Excellant. This is related to an idea I have, and its something I have dreamt about as a feature in games for a long time. Imagine a space ship approaching a planet. As the ship gets closer, the planet shifts through different LODs, starting from a simple sphere with a flat texture, right down to the paging terrain. Basically as you play the game you move from outer space right down to planet ground level, smoothly with no loading screens or dodgy tricks.
Do you think this sort of transitioning effect is possible?
Lord LoriK
Goblin
Posts: 254
Joined: Tue Feb 13, 2007 5:33 am

Post by Lord LoriK »

Quite interesting, indeed. I'd really like to know how are you planning to manage HUGE terrains. PLSM2 allocates memory for the whole terrain at startup (some pointers, bitmaps and stuff), and thats simply not possible for some cases. I was planning to do a simple paging terrain, too, because I need to handle a small planet in a 1m-per-tile scale (my terrain is procedurally generated with some areas predefined as standard heightmaps for important places) and I don't know any existing solution to handle my case...

Most terrain solutions I find are limited to a small-finite amount of terrain, something I don't like at all. Even AdVantage has a limit of 65k * 65k vertices, and that's about the larges I've found. This are practical limitations for disk-stored terrain, but it's not my case and I haven't found a more general solution. Of course, changing the scale is out of question.

You seem to support procedural terrain, but is it limited to any size?
kcbanner
Goblin
Posts: 208
Joined: Sat May 05, 2007 4:49 pm

Post by kcbanner »

I am also very interested in this. I am working on a space game and I think it would *rock* if you could fly your ship closer and closer until your skimming the surface.
User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3

Post by Praetor »

Sounds great. I've been waiting for an in-between option (more than TSM, but lighter than PLSM). Your features look great. I think the most important is the ability to use shaders and lighting, so the terrain and the objects in the world can use 1 set of lighting techniques. Also, access to vertices is great.

Can you provide a callback mechanism for page loads, so planting and object placement can be paged as well?
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218

Post by Jabberwocky »

Looks cool.

Question - will this scene manager work with straight-up pre-defined heightmap data, like TSM, or is it tied to using random terrain generation?

I'd love to have something that works just like TSM, but allows for larger heightmaps, or a grid of heightmaps.
User avatar
JamesKilton
Halfling
Posts: 87
Joined: Tue Jun 14, 2005 8:21 pm
x 1

Post by JamesKilton »

Looks good!

As for smooth planetary approaches, check out the videos for the upcoming game Infinity:

http://www.fl-tw.com/Infinity/

It's really unbelievable the amount of detail this engine can do. Unfortunately I don't think any source code will ever be available, but hopefully there's a white paper or two out of this.
User avatar
nikki
Old One
Posts: 2730
Joined: Sat Sep 17, 2005 10:08 am
Location: San Francisco
x 13

Post by nikki »

SpannerMan wrote:(Its) something I have dreamt about as a feature in games for a long time. Imagine a space ship approaching a planet. As the ship gets closer, the planet shifts through different LODs, starting from a simple sphere with a flat texture, right down to the paging terrain. Basically as you play the game you move from outer space right down to planet ground level, smoothly with no loading screens or dodgy tricks.
Do you think this sort of transitioning effect is possible?
Watch this video (from the game mentioned in the post by JamesKilton above):-
Infinity Preview
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

Ok, no particular order in answering ideas - I just woke up so bear with me if I'm sounding a bit off...

As for planetary LOD - I already have that sorta working over in my OgrePlanet project, which is buried somewhere in the Using Ogre in Practice forum. I made this terrain system because I want to test my core features for my game engine on my current PC, which is unfortunately too damned slow to debug the main problem with my OgrePlanet system (that is to say that I can only get the bug to occur in Release mode.)

As for heightmap vs. procedural content: not a problem. I just have it set up to do simple procedural generation right now (RidgedMultifractal from Libnoise), but it's very easy to pop in a mechanism to read from a heightmap or a combo-system of procedural synthesis (i.e. 20% RidgedMulti, 80% Perlin with some other fractal as the interpolator).

As for huge mapping, it currently supports 255x255 Pages of Tiles, which you can set to be however big you need to support. This can be bumped up to bigger proportions (and I'll get it in, too), but it's just this way for now due to a hash function in how I'm storing data in a std::map. I've designed it in such a way that you don't have to load everything at once - it's all on-the-fly loading. It doesn't hurt performance to load in the middle of nowhere or right on the edge (even though it wraps around.)

Shading/Lighting - It's simple plug-n-play here. You have direct access to pages and tiles, so you can set materials as you please. I'm going to have it convert heightmaps and normals to textures which you can use directly in your shader instead of doing vertex lighting.

There's more, I'm sure, and it's still in it's baby steps (I did all of this yesterday lol), so no worries if I missed something - if I didn't read it the first time, I'm sure I'll read it later when I've had a bite to eat.

Also, here's the link to OgrePlanet for those of you wanting Space->Surface LOD options. I'll say again: it's not 100% right just yet, but what's there is released and LGPL, so you can fool with it:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=30819

Thanks for the support - I'll try a new method for larger terrain support shortly and see if I can still work the hashing method in.
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

Two new screenshots for today:

Image
Image

I got normal mapping working (it actually builds normals/tangents into the vertices and/or creates a RGBA texture with the normals and heightmap) as you can see - looks pretty decent even with the LOD kicking in.

It's still all procedural, but I've got a system in place to "import" heightmaps. I also got the floating-origin system working - now the camera is always at 0,0,0 and the world moves with it and adjusts new tile geometry based on how far away from the center the camera has accumulated over time. This keeps that stupid vertex jittering from happening at huge distances.

I'll put a system in that helps you with the physics engine as I don't think it likes being jerked around all the time - basically you'd associate a SceneNode - that you'd normally attach to the physics engine to deal with - to where the movement data comes from and the engine will move it according to how much the world has moved. In other words, I move your stuff instead of one of the physics engines - I just pull the data from them and mix it with my floating origin. It will work, I promise.

I also fixed the hash function, so now you can have 65,535 Pages per side, or 65535 x 512 vertices (33,553,920 - add one for that last vertex) so, at a scale of 1 meter between vertices, you've got 33,553 km to work with, per side, or 1,125,865,547,366,400 square meters to play with. It also wraps around, but that's just for surface area of unique geometry.

Of course, if you don't want all that you can just say so in the config and limit it to X and Y amount of pages.

It's also 4 am so my above math may be off, but that looks correct to me. Feel free to tell me I goofed.

Anyways, a decent looking picture is forth-coming - I just need to write a shader/material that takes sloping from the normal map and heightmap values to do terrain splatting.

I should have the source-code here with most of the features I mentioned by Friday, but don't quote me on that.
User avatar
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
x 4

Post by Azatoth »

That looks really sweet! Just like Praetor I've been looking for a more modular alternative to PLSM2.
Ember, GPL virtual world client.
Development blog
Chimelion
Kobold
Posts: 35
Joined: Sun Mar 25, 2007 10:52 am

Post by Chimelion »

Simply Beautiful, HexiDave. I'm moving to a new job later this week, but as soon as I re-settle, I'm looking forward to trying this out.

Do you think that this new paging terrain system will be factored into your OgrePlanet system, or is it completely independent? I know that you had mentioned that this new one would have "Completely wrap-around world" paging, but I'm assuming you mean planar wrap-around, as opposed to a globe.

The reason I ask is that I have started on a debug-time visualization of your OgrePlanet which I will give back. It's based on some of your musings, but please don't hold your breath, as my new job and city is going to slow the turn-around.
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

Kudos on the debugging thing - my PC can't hack it (it's still a good PC, but it just can't pull that rip-roaring speed needed to duplicate the Release mode bug.) Take your time - I started this project just so I wouldn't have to be hassled with OgrePlanet.

This world is wrap-around planar, yes. And it's the reverse of what you said - OgrePlanet is getting factored into this :D I swiped a good bit of code from OgrePlanet to make this one work really quick. I wanted this for the sole purpose of testing my game engine stuff instead of just the planet LOD scheme. That works, but has an inherent flaw in the scheme - once I get that neighborhood to stay cohesive and put in a build queue, it's essentially done. Everything else after that is a cakewalk.

Good luck with your job - mine just fell through and I'm 100% boned for the moment since I live in a technological dead-zone and my only means of transportation is my legs.
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218

Post by Jabberwocky »

HexiDave wrote:It's still all procedural, but I've got a system in place to "import" heightmaps.
Awesome!
HexiDave wrote:I also got the floating-origin system working - now the camera is always at 0,0,0 and the world moves with it and adjusts new tile geometry based on how far away from the center the camera has accumulated over time.
I'm not sure I understand the advantage of this floating-origin system. It seems like it would cause quite a few complexities.

Lets say I have a data file specifying some hand-placed entities (in dot-scene format or whatever). I'm still going to need to be able to deal with real (non-floating-origin) coordinates to know where to place these. And, as you say, physics needs to deal in non-floating-origin coordinates somehow. I guess you could constantly convert positions between real and floating-origin coordinates, but why incorporate this extra complexity?

I dunno, it just sounds weird :)
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

Jabberwocky wrote:
HexiDave wrote:I also got the floating-origin system working - now the camera is always at 0,0,0 and the world moves with it and adjusts new tile geometry based on how far away from the center the camera has accumulated over time.
I'm not sure I understand the advantage of this floating-origin system. It seems like it would cause quite a few complexities.

Lets say I have a data file specifying some hand-placed entities (in dot-scene format or whatever). I'm still going to need to be able to deal with real (non-floating-origin) coordinates to know where to place these. And, as you say, physics needs to deal in non-floating-origin coordinates somehow. I guess you could constantly convert positions between real and floating-origin coordinates, but why incorporate this extra complexity?

I dunno, it just sounds weird :)
Make a good size mesh and put it WAY from the origin, say a few hundred thousand units. Rotate the camera a bit and watch it dance and jiggle! Welcome to the unholy land of FLOATING POINT IMPRECISION! *thunder booms and lightning crackles*

Basically the whole landscape will boil - it really does look like it - because of the fact that a "float", which is what the graphics card sees no matter what you actually feed it (you can try to feed it doubles or quads or whatever, but it WILL only get 32 bits precision), will not have the precision to handle such great distances as hundreds of thousands of in-game units without problems. This is even more apparent with character animation. If you have a skinned character (dunno how apparent this is on ninja.mesh, but try it) go place him out about 50,000 units in X,Y,Z from origin and start animating. Due to all the funky floating point inaccuracies with matrix multiplication and whatnot, it will boil.

This is where the Floating Origin system comes in and it does work. Yes, it seems like overkill (and it is for small maps, which this mostly isn't), but it's required when dealing with great distances. It should be 100% transparent to you, the editor or gamer, as it uses real-world coordinates instead of the shifted positions when saving data, and even more nicely can be easily setup (which I will do) to be local to each page or even each tile, thus you can say "Place ObjectX at position 5,5,5 on Page 4000,9333 Tile 6,6" and it will do so and load it with that page or tile, however you prefer. It won't save some giganting floating point number, but it can (probably would take less space anyways).

The FO system will also work with physics objects in that it doesn't actually mess with the physics engine that much. It MIGHT move all the physics stuff after an insanely huge shift in the origin (we're talking about an enormous game world here) - because of it using "double" precision - but, normally the engine will just move the SceneNodes containing your models by what the physics engine says each frame.

Of course you will be able to turn it off if you like; I'd imagine this being important for small levels with lots of physics objects.

Anyways, I'm working on a small exporter program that converts RAW heightmaps (will do PNGs later) to the proper format for use with this system if you're only using heightmaps. It's just a quick console app, but my system actually needs to pad the edges properly due to the way normals are calculated (to hell with neighbor nodes) - thus, if you want 1 page and feed it a 513x513 map, you get a 515x515 map with a black border. I won't go into depth of why that is, but basically it just uses what would normally be neighboring tile's heightmap's border pixels to compute normals instead of grabbing them at run-time (no needing to load neighbors just for a few pixels.)


Ok, now I see elvman asking about Manual Mesh - if you're talking about Ogre::Manual, then no, I don't think so. You build Vertex and index buffers manually and feed them into a Renderable - this is usually a custom job. It's going to take me a little bit to make this converter program (I had totally forgotten about the border pixel stuff for heightmaps when posting in your other thread), but this program does all that stuff I just said for you, so hang tight :D

Okidoke, back to work I go.
elvman
Kobold
Posts: 25
Joined: Sat Apr 14, 2007 9:59 pm

Post by elvman »

From Ogre SDK:
"Classes implementing this interface must be based on a single material, a single world matrix (or a collection of world matrices which are blended by weights), and must be renderable via a single render operation."
It means, that I have to make a Renderable for each tile (because of Single material). I guess, that this is too expensive to save world matrices for each tile. I guess I have to look for other technique.
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

Well as I said this will do everything you're looking for, it's just taking a while because my damn program won't read files into memory in a whole block like I want, so I have to re-do that real quick. I'm also about to eat dinner shortly, so in a few hours I should have this thing done and integrated and uploaded, etc.

Just wait a bit and you can play with the source code - I mean, feel free to see how Ogre works, but don't go nuts trying to solve a solved problem 8)

Edit: Also, what you said is basically how Renderables work anyways and it's not expensive to do. Each tile (there's 4 Pages of tiles in my screenshots, each has 64 Tiles, which are Renderables) only takes up a tiny bit of memory and horsepower in-and-of-itself, it's rendering the polygons themselves that chew up power, which is mitigated by Level of Detail (GeoMipMapping in this case).
Last edited by HexiDave on Tue May 08, 2007 8:49 pm, edited 1 time in total.
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218

Post by Jabberwocky »

Cool, thanks for the detailed response, HexiDave. I now understand how this would work to combat floating-point imprecision in the terrain.

I think maybe someone mentioned it already, but it would be great if there was an API to get at heightmap data as it was paged in, so we could feed the height info to the physics scene, and load in hand-placed entities or add in auto-generated vegetation/decor.

It'll be exciting to see how this progresses!
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

Jabberwocky wrote:Cool, thanks for the detailed response, HexiDave. I now understand how this would work to combat floating-point imprecision in the terrain.

I think maybe someone mentioned it already, but it would be great if there was an API to get at heightmap data as it was paged in, so we could feed the height info to the physics scene, and load in hand-placed entities or add in auto-generated vegetation/decor.

It'll be exciting to see how this progresses!
Two things: first, you can already grab the heightmap as Ogre::ushort (16 bit heightmaps) with the procedural system and file-maps (I'll set it up to support 8 bit as well, and screw you if you use anything bigger that 16 bit :P). Second, you can pull Vertex and Index buffers either singularly from Tiles as they're built or you can pull an array of Vector3's with vertex positions of the whole Page. I'll also have support for RaySceneQueries for simple placement stuff.

Edit: Oh ya, also (as seen in the last 2 screenshots) you can build a 4 byte (RGBA) texture map with 3 bytes for normals and 1 byte (alpha channel) for the heightmap so that you can feed it to a shader. I'll support 16 bits per channel as floating points and any other useful texture formats worth supporting. The neat thing is that you don't need to feed this system a normal map, it builds it right off of the heightmap (it's fast as hell, so no worries about slowdown) and is also "neighbor-friendly", such that neighboring Pages don't show seams - each page has border info in the heightmap to calculate neighboring Page's normals :D
Lord LoriK
Goblin
Posts: 254
Joined: Tue Feb 13, 2007 5:33 am

Post by Lord LoriK »

HexiDave wrote:and screw you if you use anything bigger that 16 bit :P)
Damn. Time for plan B, then. Hehehe. :)

I'm really impressed by the features you're mentioning. But I have a few questions: do you manually move al the scene nodes when moving the camera? Isn't that slow/inefficient? Wouldn't be better to move the origin only when needed? (when is need is something you define considering the floating point accuracy loss, ie, when the floating point epsilon gets too big to be noticeable)

My other question is: how much memory do I need to get a 1,125,865,547,366,400 square meter area?

Sorry if you already addressed some of this questions before I asked, but I have no time to read the whole thread (sorry, really) and yet I'm too excited to keep myself from writing.
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

Lord LoriK wrote:
HexiDave wrote:and screw you if you use anything bigger that 16 bit :P)
Damn. Time for plan B, then. Hehehe. :)

I'm really impressed by the features you're mentioning. But I have a few questions: do you manually move al the scene nodes when moving the camera? Isn't that slow/inefficient? Wouldn't be better to move the origin only when needed? (when is need is something you define considering the floating point accuracy loss, ie, when the floating point epsilon gets too big to be noticeable)

My other question is: how much memory do I need to get a 1,125,865,547,366,400 square meter area?

Sorry if you already addressed some of this questions before I asked, but I have no time to read the whole thread (sorry, really) and yet I'm too excited to keep myself from writing.
First answer: I do indeed move all the SceneNodes every frame and it doesn't seem to slow it down much, if at all. The main reason I don't do it every-so-often is for a reason I noticed on my first planet engine prototype: it jumps. It might not be so bad with this implementation and adjusting it is as easy as adding a pause mechanism, but that's what I've been doing so far.

Second answer: a lot. But that's only if you're silly enough to try loading it all into memory, which would break down pretty quick. The whole system revolves around building data when - and only when - you NEED it. Each page is completely self-sufficient, so it doesn't need neighbor info of any kind before-hand. It uses a hashing system to figure out if it has neighbors for LOD changes and all the heightmap-edge data is stored with the page's heightmap (i.e. surrounding Page's heightmap edges are on the 1-pixel border of this heightmap).

I'm making progress on the RAW file converter such that you can use RAW heightmaps instead of procedural, but I keep running into stupid bugs (it's a lousy programming day for me, apparently) - I'm at the heightmap splitting part, so I'm almost done with that. Integration won't be a problem with the main project, though (I say that now, of course...)

Edit: Oh, and if you want to use larger map types for procedural, like floats, it'll be pretty easy to put that in, but it'll probably be a compile-time option like some other things I've got going.
User avatar
deficite
Gremlin
Posts: 160
Joined: Sat Oct 15, 2005 4:31 pm
Location: TN, USA

Post by deficite »

Sounds good. Just like others have mentioned, I want something between TSM and PLSM2 (PLSM2 is just way too complex and heavy for my tastes).

The floating-origin thing worries me a bit, but I'll wait until I can try out your work before casting judgment.
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

As I said, it's mostly for large terrains and, again, it IS needed for large scale maps. Any game with large worlds has to move the origin around.

For now, it's commented out and I'll even have some instructions with it on how to use it since it's pretty easy. It's not 100% done - that is it won't integrate well with Physics engines just yet (this first release is just going to be so people can play with it and look for bugs and bitch about stuff ,etc.), but it'll work fine later on and have a lot of little handy tools to help you with object placement, networking, etc.

Quick update: map-splitter for RAW heightmaps and padding them properly is done. Reading heightfields instead of procedurally generating them is done. You could theoretically mix and match at this point with some procedural tiles and some heightfields, but it would look pretty stupid :D I'll have a feature later that interpolates from one into the other gracefully.

What's not in: wrap-around. Automatic terrain loading (you gotta do all the construction for now). Floating-origin is sorta in but I disabled it since it's so unusable for now. Retrieving vertices in a Vector3 format (sorry, I forgot I had moved that into the generation part - I'll move it back later). Uh, I dunno - there's a bunch of stuff not done yet. I mostly stepped this up as a quick release so people could mess with it.

What's in: Loading pages from heightmaps on file or procedurally with Libnoise (right now it's only RidgeMultifractal, but I'll change it later - see other posts about that). Builds normal maps with either procedural or heightmaps from the disk. The heightmap splitter program is in it's infancy, but it works. You can pull heightmaps from a page. You can pull Vertex/Index buffers from a Tile. Page/Tile/Heightmap/NormalMap/Texture destruction is automatic (if you use the "feeder" system). Custom materials per Page and per Tile through a setMaterial() type command.

Not sure what else is there. I'll upload source code along with the Libnoise directory (only takes a second to setup) in a few minutes - I have to package a few things up and make a small Readme.txt type file.
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

Ok, damn, what an ugly release this is lol.

Included is the splitter code, the terrain code, libnoise and a big Readme file that you'll probably need to read in order to survive the journey of setting this thing up.

I'll create a proper project file for it later, but for now you're stuck a bit.

Have fun, lemme know if something works or not, etc.

Here's the link: http://www.fileden.com/files/2006/7/10/ ... errain.zip
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218

Post by Jabberwocky »

Cool, I'll finish up my current project, and dig into this sometime next week.