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

[mikeInside]

Looking good! I've read that mixing terrain with nxOgre is a little tricky at the moment... a simple way of doing so would be awesome. You mentioned in the first post of this topic integrating it with nxOgre... any progress on that?

[HexiDave]

Well if I could get nxOgre to compile I'd be all set

But, no, that's not quite there on my list of "what to do today?" After a hellish fight with namespaces (which I seem to have lost) I'm about to call it a day, but later on I'm going to fix that and try to add a configuration system, the splatting texture loading system (and subsequent texture systems), upgrade the material handler (such that you can just tell it to adjust the material it's fed so your custom textures are loaded in automatically), add a few user-end tools so they can work with the floating-origin system (which is working and can be shut off) and some other things I'm too tired to remember.

That wrap around system kicked my ass pretty good and I'm pretty unhappy about that, but the results are good and I'll get a fade-in, fade-out system so the tiles don't pop into and out of existence.

Anyways, on physics, at the present it's a bit murky because of the floating origin system, so I want to get nxOgre and OgreNewt compiled (I'll try to do OgreOde as well, but I've never used it) and do some test runs before I say "go for it", but if you shut the floating origin system off and just pull the Vector3 or heightmap data and process it with the physics engine, it should work ok.

Expect a release late Friday night, early Saturday morning.

[Rockpsl76]

Looks nice!

I second the suggestion to support the use of DEM data ( *imagining* Total War at a global level )

[HexiDave]

Ok quick update:

Lord LoriK: I've implemented your suggestion to fix up namespaces, the preprocessors to constants (and regular settings) and I cleaned up the header inclusion, so now it compiles about 50x faster.

Nothing major to report, but that was screwing with me last night and it's a huge upgrade for me because I kept getting computer problems when my memory would cap out and roll into paging memory, so my whole system would lock up from a quick compile...

Rockpsl76: Never played it, but if you mean "global level" like having a planet, then you'll have to wait for me to finish this project and get back to my planetary rendering project, but this supports HUGE terrain, although it's "flat" in that if you start leaving the atmosphere it's just a flat planet.

And, yes, I'll support DEM loading soon - might try including it today if I have time.


I'll try to write up a road-map of planned features after the next release.

[Lord LoriK]

Lord LoriK: I've implemented your suggestion to fix up namespaces, the preprocessors to constants (and regular settings) and I cleaned up the header inclusion, so now it compiles about 50x faster.

Glad to know that! My humble opinion was heard by an Ogre Expert!

this supports HUGE terrain

I'll give it a try when the interfaces get solid enough. I really need a HUGE (cannot emphasize the word HUGE enough)...

I hope you manage to make a release this weekend, as you said some posts before.

[HexiDave]

I'm working on wrapping the terrain heights now (such that there are no seams - almost got it working, it's just being finicky), but on large terrain:

It easily supports 65536x65536 PAGES of terrain. At 513x513 vertices per page, that's 33,554,433x33,554,433 vertices - of course not displayed all at once, but that's the total size. Now, if you have a scale of, say, 5 meters between vertices, you have a total, non-wrapped distance of 167,772,165 meters, or 167,772 kilometers. That's 28,147,499,348,787,225 square meters of space. The Earth, in comparison, has 510,065,600,000 square meters of surface area, which is 1 / 55184 the size.

Will that do?

[kneeride]

>>510,065,600,000

holy smokes. tell that to the artist who has to provide the content

[Lord LoriK]

It easily supports 65536x65536 PAGES of terrain. At 513x513 vertices per page, that's 33,554,433x33,554,433 vertices - of course not displayed all at once, but that's the total size. Now, if you have a scale of, say, 5 meters between vertices, you have a total, non-wrapped distance of 167,772,165 meters, or 167,772 kilometers. That's 28,147,499,348,787,225 square meters of space. The Earth, in comparison, has 510,065,600,000 square meters of surface area, which is 1 / 55184 the size.

Will that do?

I think so! I only need about 26 million square kilometers with 1 meter between vertices.

And if you allow me to correct you, every page has 512 useful vertices only, because the 513rd one is shared with the next page (being the first vertex of that page). If they wrap, you have 512 * number_of_page vertices; if they don't you have 512 * number_of_page + 1 vertices.

>>510,065,600,000

holy smokes. tell that to the artist who has to provide the content

The artist? CG content will do, of course!

[kneeride]

you thought I meant the artist was going to do a monet?

[HexiDave]

Lorik - I did mean 513x513, but I did the math with 512x512 and added an extra vertex on the end - should be accurate

As for content - this is based mostly on procedural synthesis, so a lot of it is made as you go along! I'll create a way to render a mini-map file later on so you can see what your map looks like.

[HexiDave]

HA HA! Great success!

I've adjusted the procedural synthesis code for wrap-around to use torus coordinates - now there are no seams! Works with the normals as well, so that's a huge relief The original plan to "fade" into the wrapped heights didn't work AT ALL. I realized that what I was visualizing was flawed and stumbled upon a post on GameDev.net about using Torus coordinates and it works like a charm.

So, I'm in a rather good mood now and that's a huge chunk of work I don't have to worry about.

Also, I have a basic DEM loader, but I'm going to try to build a proper file-loading structure along with my config-file system first.

So, in other words, things are looking good

[REiNDEeR]

Doesnt sounds like "small" anymore Looking forward to the release hehe

"simple" i mean..

[Lord LoriK]

Something came to my mind a few minutes ago: what happened with the heightmap precision? Last time you said something about that, it was limited to 16 bit data. Do you have plans of using/allowing 32 bit data, or some exotic value like 24 bits? Maybe 16 bits with a 32-bit offset for each page?

[HexiDave]

Ya, that was mostly set to 8 or 16 bit terrain RAW files before, but it's an easy matter to switch it to 8,16,24 or 32 now - I'll have a PNG loader as well sometime today.

And it's still a fairly simple setup - a lot of "I want Page 0,4's Heightmap - call MasterModule::getInstance()->getPage(0,4)->getHeightmap()" type things make it fairly easy to use.

I just wanted something you can add a header into your project, add the library, give it some base parameters and you're good to go.

[Lord LoriK]

I just wanted something you can add a header into your project, add the library, give it some base parameters and you're good to go.

KISS principle. Just love it! I get more excited with every detail you mention...

[trilobite]

I've been trying to keep up with all the rapid activity by HexiDave. Dude, you are going like a bat outta hell. It's fun to witness how a skilled programmer integrates so many difficult elements to create something so useful and beautiful. Quite a remarkable phenomenon indeed. Yessiree!

Everybody just stand back and watch the man work. And try not to get too close, 'cause this guy is ON FIRE, baby!

[HexiDave]

Ha ha, just a bored guy with a goal, that's all Thanks for the kind words, though.

I'm working on the 1-4 byte per pixel thing now and I'm realizing that my template idea isn't working like I'd hoped, so I'm gonna have to rethink it a bit. I never worked with run-time setting of types before, so this is a bit... interesting. Hell, I'm not even sure if it's possible =/ If worse comes to worse I'll store everything as "uchar" and make it pick 1-4 bytes from the array and build the proper value with bitwise math.

[KungFooMasta]

wow, uchars and bit level math, that is pretty low level! (for me at least!)

I agree with trilobite, I was wondering how you are able to put in so much! Don't hesitate to take a break if you need it, you don't want to burn out.

[HexiDave]

Heh, don't worry - you'll know when I burn out

That wrap-around thing made me tired... then I saw what I was doing wrong and I was so furious I couldn't sleep, so I got it all done pretty quick after that

I've just about got the 1-4 byte thing working, but I hit a bug somewhere in all the changes I just made and some tiles look right while others are crazy jaggy spikes. Probably a typo somewhere and the values are wrapping around or something stupid...


Edit: Found it -

Code: Select all

const uint iPos = (ix * mBytesPerPixel) + (iy * mMapPixelWidth);

Should be

Code: Select all

const uint iPos = (ix * mBytesPerPixel) + (iy * mMapPixelWidth * mBytesPerPixel);

Basically my array wasn't being accessed properly - works fine now for 8,16,24 and 32 bits per pixel heightmaps.

[HexiDave]

Quick update:

Had a huge hassle with std::queue (again) with the BuildQueue system - you can see what happened over in the Back to Basics section, but the short of it is: std::queue<> can kiss my ass.

Anyways, the BuildQueue works for Heightmap generation, building tiles and will soon work for file loading (won't be hard to introduce it now).

I should have Ogre's Resource system integrated shortly as well as DEM heightmaps and PNG loading for heightmaps.

I've encapsulated (think that's the right term) the noise generation mechanism such that you can now feed it x,y coordinates and it'll feed a Noise class (which you abstract from) a set of 3D coordinates for Torus coordinates, or you can just use your own home-made wrap-around 2D noise synthesis. I originally had an idea for reversing heightmaps around the borders such that they'd wrap properly, but it was a bust, so this is the way to go for now. I'll try it again as I could have easy just bungled it, but you can always use custom heightmaps around the borders if you so choose.

I got nxOgre compiled last night, but sadly OgreNewt refuses to let me use Double Precision mode in a compile - I worked over the code pretty solidly but hit a roadblock and couldn't make the conversions work any further. Having said that, you don't HAVE to use Double Precision mode for this thing, I'm just using it because I already had it compiled this way... I'll try to integrate a physics system for tests tomorrow'ish and see how it responds to being jerked around by the Floating Origin system.

On that same note, the floating origin system saw some improvements and now has a few little utilities so you can find your real position, instead of in relation to the shifting camera coordinates.

For now file-loading is a bit weak, but I'll soon have an in-system editor so you don't have to worry about importing, splitting, working with borders, etc. I don't want to worry about it either, so I'll get it together as soon as I can. It'll just let you use a set of brushes either in a 2D window or 3D push/pull on the terrain itself and then export the heightmaps that way (would be easiest).


Dunno what's left on my list for right now - I have to finish up the Page destruction system, but that's a given and I think I mentioned using shaders to optionally fade a page out of existence rather than just having it pop out of view.

Hmm, I'll have to review this thread as I got derailed again on that stupid BuildQueue to see what else I wanted to do and what was suggested to add... I'll also write up a list of exactly what's planned after the release tomorrow.



Feel free to keep posting ideas - I may forget one here and there, but if it's written down here I'll get to it eventually.

Thanks for being patient with me - not used to having my code fight me so much

[jacmoe]

Thanks for being patient with me - not used to having my code fight me so much

That's the backside of the Ogre Expert User medal!

[Lshink]

This project looks promising, I just had one question to ask about it.

Are there any plans to use a more sophisticated LOD technique then Geomipmapping? Perhaps some continous LOD technique like geomorphing -- on the GPU?

Just curious, as it is what I am currently attempting to do

[HexiDave]

Yep, I'll have the LOD mechanism separated a bit so you can add your own in fairly easily, but I do intend to do continuous LOD as well as a refining GeoMipMapping system where as you get closer, the heightmap fills itself in more through refinement (or file-loading) and will use LOD accordingly (I wrote about this a page or 2 ago in this thread).

My schedule today is a little backed up, but I should have a release sometime tonight. I won't be able to get DEMs in like I thought I would, but I should have this thing in a usable state so people can start playing with it a bit.

[HexiDave]

I have to push the release back a bit - more work came up (stupid life!).

Again, sorry for the delays (please don't kill me )

[nemro]

This looks like a promisingly
terrain engine.

I have also a question, how efficiently is it or how inefficiently are the
trees or the skybox?
If I use it here, I get about 600 to 1000 fps without trees and sky.
But with sky and trees just 70 to 250 fps.

I would like to see it with Nimble and SpeedTrees.

Feel free to keep posting ideas - I may forget one here and there, but if it's written down here I'll get to it eventually.

Its not a idea about a specific feature, but we could collect all promising terrain features from nextgen
engines. Maybe some of them could be integrated in this terrain engine.

nemro