New Terrain Early Shots

[DanielSefton]

Nice! Makes my PNG heightmap with no splatting terrain look crappy. That certainly does it justice...

(pure guess: Tazmania???)

Did you use L3DT? 2048x2048?

I have to say, this terrain system is growing on me - you have so much freedom with it not being a scene manager, it doesn't 'get in the way' of anything, and I've crossed off 10 issues I had with MyRddin from our tracker

[jacmoe]

Some screenshots from my terrain experiments. Anyone recognize the island?

Spectacularly awesome!

[sinbad]

Haha, that's awesome - the Ogre head as an island

[jbb]

Very very nice work.
One question, is there any support for "holes" in the terrain for adding meshes for caves and entrances and stuff that go through the terrain?

[aguru]

Did you use L3DT? 2048x2048?

I used World Machine Pro and it's a grid of 5x5 pages a 513 pixels = 2560, about 25 MB raw float 32. World size is about 10x10km, so resolution is about 3,9meters per pixel.

And yes, it's indeed ogre island

[sinbad]

Very very nice work.
One question, is there any support for "holes" in the terrain for adding meshes for caves and entrances and stuff that go through the terrain?

Not geometrically in the terrain, it would make things too complicated. But you can do this sort of thing with stencil cutting - you basically render the terrain first, then render a piece of 'carving' geometry with normal depth testing, and write to the stencil buffer where it passes. Then you clear the depth buffer where that stencil test passes and then render your final cave geometry which fills in the gap that has been left.

[DanielSefton]

Finally got raw heights working! No splatting yet.

How do I remove those black seams at the edge of each page? (on the first image) Do I need to lower the 'pixel error'?

Oh and I'll sneak a couple more shots in there just because they're cool.

[aguru]

Very cool pictures. I think we are going to see more of those in the next weeks

How do I remove those black seams at the edge of each page? (on the first image) Do I need to lower the 'pixel error'?

Whats the resolution of your raws?

[DanielSefton]

Whats the resolution of your raws?

513x513. Although L3DT can only generate maps of 512x512, and I had to use the resize on export option, not sure if that has anything to do with it. But I had the same problem even with the PNG heightmap. The seams disappear as you get closer.

[sinbad]

If they're gaps, Make sure that you've set your skirt size appropriate for the scale of the rest of the geometry and the pixel error you're using. The new terrain system doesn't stitch, it uses skirts to hide the gaps instead.

[DanielSefton]

Oh, I know what they are now. When the composite map covers the edge of a page, those black seams appear.

[sinbad]

That doesn't happen here though, my composite maps are seamless. What happens if you dirty the edge region after the group is set up? I'm wondering if this is a timing issue regarding the calculation of the composite map and lighting and the setup of the neighbours.

I also notice that your lighting isn't calculated properly, and you havea serious dfiference between your composite map and the close detail. It seems like you have some calculation issues generally that I don't have here.

[aguru]

Daniel, are you getting those seams only when loading the terrain from ogre's file format or also when you fill in the data yourself?

[sinbad]

Daniel, are you getting those seams only when loading the terrain from ogre's file format or also when you fill in the data yourself?

Either should work though - in my case the terrain is imported from PNG the first time you run the demo, then it writes out the data files and subsequent runs of the sample pick those up instead. I get no seams either way. It looks to me like the composite map has been saved before the lighting was properly calculated or something. In the demo, I wait for all the derived data processes to finish before saving the data - maybe Daniel saved straight away or something so ended up 'baking' incomplete lightmaps into the data files?

[DanielSefton]

That doesn't happen here though, my composite maps are seamless. What happens if you dirty the edge region after the group is set up? I'm wondering if this is a timing issue regarding the calculation of the composite map and lighting and the setup of the neighbours.

Doesn't seem to have any effect. You mean call dirtyRect() then update(), right?

I also notice that your lighting isn't calculated properly, and you havea serious dfiference between your composite map and the close detail. It seems like you have some calculation issues generally that I don't have here.

Yeah; I thought it was because of Caelum, but it's exactly the same with it disabled. Same with lightmapping on/off as well.

Daniel, are you getting those seams only when loading the terrain from ogre's file format or also when you fill in the data yourself?

maybe Daniel saved straight away or something so ended up 'baking' incomplete lightmaps into the data files?

Well, I'm filling the data myself with pretty much the same code from the sample. I've not used the dat files yet.

I'll continue testing; if it's not supposed to happen, I must be doing something different. But it's not like these problems have only just emerged, they've been happening since I integrated it, just wasn't as noticeable.

EDIT: Okay, the skirts are completely black around the parts that the composite map covers.

[jbb]

[quote="sinbad]
Not geometrically in the terrain, it would make things too complicated. But you can do this sort of thing with stencil cutting - you basically render the terrain first, then render a piece of 'carving' geometry with normal depth testing, and write to the stencil buffer where it passes. Then you clear the depth buffer where that stencil test passes and then render your final cave geometry which fills in the gap that has been left.[/quote]

That makes sense, thanks.

[sinbad]

@Daniel: yeah, something is definitely wrong with both your lightmaps and your composite maps (which could be linked). When you call dirty() and update(), remember that the lighting update is deferred, it's not finished when you return from that call. Use isDerivedDataUpdateInProgress() to determine when everything is finished, at which point your lightmaps & composite maps should be ready. Before that, it's not going to look right. I get no issues like that with my composite maps or lightmaps, but maybe you're just not waiting for them to be finished. This is why I use the dat files after the first run, because they already have all the calculations done so I don't have to wait.

[aguru]

sinbad, I too get an error with wrong colourmaps. the strange thing is, everything looks ok when I import my data. once texture calculation is done everything looks fine and the ogre-terrain-dats are written.
when I restart the example and it uses ogres dats it looks like this:

4.jpg

This is with a 5x5 grid a 1024 (heightmap is scaled to 1025).

Would you be interested in my terrain data (3x3 512 should be sufficient) and a patch to my sample Terrain.h? I don't want you to debug my stuff but it might help you debug, too.

[boyamer]

Nice work sinbad,you've done well job,i saw there is a TODO into MaterialGenerator about shadow maps,
that would be great,with PSSM shadows

[sinbad]

@aguru: that's very odd, because I don't get that problem with my tests. Do you get it with the standard terrain demo? The one in svn only uses 2 pages but that should be enough to test - I didn't scale it up to 9 pages because people would have to wait longer for it to calculate- obviously in production environments they'd distribute the precalculated media but I'm keeping the size down.

Maybe it's related to hardware. I've obviously got your import data now so I can check but I'm buried in the paging component right now...

[edit]I also notice that it's still got the 'computing textures...' message at the top, that means it's not finished yet...

[Brutal]

The terrain instances are just world objects, you can place them within any SceneManager you like. But regarding seamless WoW type worlds, probably the grid-based paging is all you'd really need.

Does this SM have that? I havent really looked into it too much, ive been wasting a bunch of time trying to figure out PCZSM, but if this would work fine that would be great. Having a SM thats developed by you would be much more preferred. My only worry is occluding geometry which I know PCZSM does, but im wondering if this does as well. Basically if an area cannot be seen, then its not rendered. Does this do that as well?

[DanielSefton]

Does this SM have that? I havent really looked into it too much, ive been wasting a bunch of time trying to figure out PCZSM, but if this would work fine that would be great. Having a SM thats developed by you would be much more preferred. My only worry is occluding geometry which I know PCZSM does, but im wondering if this does as well. Basically if an area cannot be seen, then its not rendered. Does this do that as well?

This new terrain isn't a scene manager, like sinbad said, it's just a world object, you can use it with whatever scene manager you like.

So for "if an area cannot be seen, then its not rendered", then you would load the octree scene manager as usual. Of course, you can use PCZSM with it too.

PCZSM works on the concept of portals and zones, so in terms of WoW-type worlds my guess is that it would work nice for indoor/outdoor transitions. The new terrain, as a world object, could be contained in the root zone, and you would load/unload the pages as you walk from/into a child node (portal). That's what I'm thinking about implementing myself, I hope this is what sinbad recommends for indoor/outdoor support pre-v2.0.

For outdoor-only seamless worlds, you don't really need PCZSM - simply use regular terrain paging, and implement your own visible object proximity, which is what I'm doing ATM.

[KungFooMasta]

DanielSefton,

Can I ask what FPS you get with the screenshots you posted? Are you using debug or release mode, and what are your hardware specs? I'm just curious, I'm working with debug on everything and my FPS is insanely low, not particularly due to the Terrain, but I'm wondering if a lot of people tend to work in debug or release.

[DanielSefton]

Can I ask what FPS you get with the screenshots you posted? Are you using debug or release mode, and what are your hardware specs? I'm just curious, I'm working with debug on everything and my FPS is insanely low, not particularly due to the Terrain, but I'm wondering if a lot of people tend to work in debug or release.

It's in release mode "with debug information". FPS varies a lot, according to how much "stuff" is in view. With the sky, water and terrain I get 25-30 FPS with everything in view (if I look at the ground or into the sky, I get 40-50 FPS). The foliage depends on the density - with about 1000 trees 20 FPS, with dense trees (5000+) and grass, 10 FPS. Bearing in mind that I have parallax mapping disabled and only a single splatting layer, that saves about 15 FPS.

Specs of my PC are:
Pentium 4, 3.4 GHz
1.5 GB RAM
nVidia GeForce 6600 256mb

I personally don't work in debug most of the time, it's far too slow like you said. I only switch to debug when I need to debug something nasty or solve a deep crash. I just like to get a feel of the actual game experience while I'm developing. Like I said, I have a "release with debug info" configuration, so I still get stack traces. I also have an optimised release configuration to test true performance, though it's not massively different.

[al2950]

Never run Ogre in Debug unless you really need to!! My app, which normally runs at 50-60 FPS, runs below 1 FPS in debug!