New Terrain Early Shots

[stealth977]

I guess I meant input scale not bias. So basically if I want a terrain that ranged from min y = -500 to max y = 500, my input scale should be 1000. I guess I was thinking image input values would be [0-255] instead of [0.0-1.0]. So input data from an image is converted to 3d world heights (using input scale/bias), whereas if we supply an array with data to create the terrain, the array needs to contain 3d world heights already (no input scale/bias used). Is this right?

Yup, its right, if you supply a float array, the values passed are used as is without any scaling or bias.

ismail,

[Oceax]

The terrain normals are calculated in a background thread (assuming you have Boost available), therefore there may be a slight delay in the lighting appearing (this is deliberate, it shows the threading is working!). I've never had it take more than about a second on my machine though, although that will get longer as I add shadowing. When the data is loaded from a terrain file rather than built from an image or raw data, the data can be loaded rather than calculated for a faster initial display. If it never appears, check the log for errors, maybe the background thread crashed out or something. I'm fixing things all the time...

I was not using boost before because cmake didn't find it. I fixed that and now with Ogre using boost i always get light immediately on terrain but now there is no splatting suddenly (only dirt texture) , There is no code change in my program (same as playpens), the only thing i changed was to make boost available in Ogre. But everything looks correct in playpen.

[sinbad]

I was not using boost before because cmake didn't find it. I fixed that and now with Ogre using boost i always get light immediately on terrain but now there is no splatting suddenly (only dirt texture) , There is no code change in my program (same as playpens), the only thing i changed was to make boost available in Ogre. But everything looks correct in playpen.

Then you're doing something wrong I can't answer this without any details about what's different between PlayPen and your app.

[sinbad]

Getting close! If anybody has saved/loaded the new terrain from file, please post.

I've fixed a few bugs in the save/load process, and now loading the saved data file including the lightmaps etc seems to work fine. It's also hugely faster at startup than importing!

I also added some convenience methods so you can load/prepare/save using vanilla filenames if you want. It's not as powerful, and not what I'll use in the paging system, but it's more friendly to the wider audience I guess.

[edit]Oh, and I'm aware of a weird LOD 'flickering' effect in the distance after loading a saved terrain, I thought I'd found the cause of this but obviously not. I'll have to come back to that one later. There will be another short pause in development as I have a bucketload of others things to be doing next week!

[sinbad]

Fixed some bounds calculations which were screwing up the LOD in some cases.

[sinbad]

Ok, now I'm definitely done for the moment I've fixed a whole bunch of bugs with LOD, particularly in release mode, and things are much smoother & more stable now, LOD changes are much harder to spot.

[aguru]

It's great watching your progress in realtime

[jacmoe]

I can only second that!

[Xplodwild]

I tried BlendMap realtime editing, modifying PlayPen like that :

Code: Select all

if (mKeyboard->isKeyDown(OIS::KC_SPACE))
				{
					Vector3 tsPos;
					mTerrain->getTerrainPosition(rayResult.second, &tsPos);

					size_t x = tsPos.x * (mTerrain->getSize()-1);
					size_t y = tsPos.y * (mTerrain->getSize()-1);
					/*float addedHeight = 250.0 * evt.timeSinceLastFrame;
					float newheight = mTerrain->getHeightAtPoint(x, y) + addedHeight;

					mTerrain->setHeightAtPoint(x, y, newheight);*/


					mTerrain->getLayerBlendMap(1)->setBlendValue(x,y,255);
					mTerrain->getLayerBlendMap(1)->dirty();
					mTerrain->getLayerBlendMap(1)->update();
					mTerrain->update();

				}

But when I press space, I see no changes (I press it on a zone where there's no texture 1 already blended, naturally).
So, what's wrong?

Edit: I also tried converting x and y to image space, and I still cannot see any changes

[sinbad]

Your code isn't quite right. This works fine for me:

Code: Select all

				if (mKeyboard->isKeyDown(OIS::KC_SPACE))
				{
					Vector3 tsPos;
					mTerrain->getTerrainPosition(rayResult.second, &tsPos);
					TerrainLayerBlendMap* map = mTerrain->getLayerBlendMap(1);
					size_t imgx, imgy;
					map->convertTerrainToImageSpace(tsPos.x, tsPos.y, &imgx, &imgy);

					map->setBlendValue(imgx, imgy, 255);
					map->update();

				}

Remember, it will only work where layer 2 upwards isn't overwriting it. In the PlayPen test, that means you'll only see it on top of the brown dirt areas at the lowest points of the terrain. You'd have to also 'unblend' layer 2+ to see it otherwise. Editors would normally have to handle this if they want to support arbitrary painting regardless of layer ordering.

[Xplodwild]

Thanks, it works very well. And thanks again for your great work
I'll probably make a little editor demo.

[Xplodwild]

Okay, I played a bit with it and it's really a great plugin.

I've noticed two bugs :

- First is a culling related bug, when you make a high hill, and the "base" of the tile isn't in the camera frustum, the tile just disappear, making the hill disappearing too :

http://img339.imageshack.us/img339/8936/cullingbug.jpg

To reproduce this bug, simply take a flat terrain with one big hill in the middle. Then, look only the hill (flat terrain outside of the camera view frustum).


- Second is a lightmap bug, when the terrain is first flat and you make some basic hills, the lightmap will stops next flat tile, until you deform the tile. Once the tile is deformed, everything works well :

http://img249.imageshack.us/img249/4614/lightmapbug.jpg

To reproduce this bug, take again a flat terrain, and make again one hill. The shadow of the hill will stop at next tile.

[sinbad]

Thanks. Since I'm getting some reports but have no time to look at them just yet, I'm stacking them up in the Bug Tracker until I get chance.

Known bugs are here: Terrain Bug List

[Xplodwild]

I've another bug, really strange.

I've done a little function to copy edges from one terrain to another terrain, to do seamless terrains. It's just a loop which uses getHeightAtPoint and setHeightAtPoint. But once this operation is completed, I get an Ogre Exception :

13:19:01: OGRE EXCEPTION(3:RenderingAPIException): D3DXLoadSurfaceFromMemory failed in D3D9HardwarePixelBuffer::blitFromMemory at ..\..\..\RenderSystems\Direct3D9\src\OgreD3D9HardwarePixelBuffer.cpp (line 583)

Even if the result shows on the screen before this exception occurs (and the result is good, ofcourse). If, instead of doing a for from 0 to getSize()-1, I do it from 1 to getSize()-1, I can move around a little bit before the exception occurs.

[sinbad]

Please log this in the buglist, but please also provide a repro case rather than just a description. It will get looked at faster that way.

[Ter13]

So for the time being this is complete pending buglists?

What's missing from what you would call a "final" release candidate?

[sinbad]

So for the time being this is complete pending buglists?

If it's not, people should add things to it I fixed a couple of things over the weekend, but I'm still occupied with other work most of the time right now, will return to this when I can.

What's missing from what you would call a "final" release candidate?

From my previous post, amended:

[s]- fixing the ray query (in progress)[/s]
- Shadows (options for real-time [s]and baked[/s])
- Fog
- Fallback profiles for SM1 and fixed function (also GLSL for higher profiles if needed)
- Material LOD - drop parallax first, then normal mapping later
- paging integration refinements - normal/shadow calculation between pages for example
[s]- real-time editing tests (code is there, but not really used yet); might be able to delegate this to others like stealth977 [/s]
[s]- LOD tweaking - I can still see an occasional pop which I think is down to the LOD fading not always dealing with the transition up the hierarchy properly[/s][s][/s]

[Praetor]

Sinbad, have you tried a material with just one texture yet? The idea would be for LOD, to start with splatting shaders up to a certain distance. They fade out to just a base texture. Then after that no shaders are used and just a material with that base texture. I'm finding the terrain very pixel shader bound right now. When I try just a single texture splatted over the whole terrain, I get some weird tiling artifacts. I'll post some screenshots later.

[sinbad]

Sinbad, have you tried a material with just one texture yet? The idea would be for LOD, to start with splatting shaders up to a certain distance. They fade out to just a base texture. Then after that no shaders are used and just a material with that base texture. I'm finding the terrain very pixel shader bound right now. When I try just a single texture splatted over the whole terrain, I get some weird tiling artifacts. I'll post some screenshots later.

If you mean baking the splatted layers into one diffuse texture for the distance, yes that's intended to be part of the material LOD.

Haven't seen any tiling artefacts, I generally start with one texture when I'm starting from the flat terrain and that's been fine.

[Praetor]

Well, it works using the existing splatting shaders to splat a single texture, the problem I'm seeing is when I don't use any splatting shaders, but just a material with a single texture unit (fixed-function).

[Xplodwild]

- paging integration refinements - normal/shadow calculation between pages for example

What have you planned for paging ? For example, how to keep two terrains seamless ? To edit them seamlessly ?

[sinbad]

Well, it works using the existing splatting shaders to splat a single texture, the problem I'm seeing is when I don't use any splatting shaders, but just a material with a single texture unit (fixed-function).

Ah ok - in fixed-function you'd need to set up a FF texture scaling to match what the shaders to to rescale the UVs, otherwise the texture will just be displayed once over the entire terrain. I intend to actually remove the UVs when fixed-function is not being used because the vertex shader can generate them, but the option will be there for FF materials.

- paging integration refinements - normal/shadow calculation between pages for example

What have you planned for paging ? For example, how to keep two terrains seamless ? To edit them seamlessly ?

I want to have some kind of boundary notification interface, details not quite decided yet. But yes, it would allow the seams to be synchronised; that's the easy bit really, more tricky is how to cast baked shadows between pages.

[moagames]

How is the plan for real time shadows ?
E.g. if i want to use pssm shadows, how will i have to set up this ? will it be directly supported or will i have to use a custom material for the terrain ?

[Praetor]

There's mention of horizon maps in the source.

My goal was to have the texture spread across the whole terrain, but it appears to also somehow get distorted by the tiles as well. It's a really odd effect, but I can tell it is being affected by the tiles because as I move around, the warping changes as the LOD changes.

[sinbad]

The lightmap, normal map and colour map is just a texture stretched across the entire terrain, I don't see this effect with that. It could be the vertex format is upsetting the FF pipeline, I haven't tried yet.

How is the plan for real time shadows ?
E.g. if i want to use pssm shadows, how will i have to set up this ? will it be directly supported or will i have to use a custom material for the terrain ?

There's mention of horizon maps in the source.

Yeah, I'm ditching horizon maps. Real-time shadows means shadows from objects onto the terrain, not shadows from the terrain itself. Real-time shadows for casting from the terrain itself just won't work, because the fidelity in the distance will be terrible, and the features so large that it will be glaringly obvious. I have used horizon maps before to speed up lightmap calculation on the GPU (I'd still only calculate it when there's a change), but I'm using threads to build the lightmaps now and I'm preferring the flexibility that gives me - not only am I not restricted on the light angle (horizon maps have to be precaculated for a given single sun track), but the update doesn't slow down the GPU which is already being used more for the per-pixel effects. The lightmap update is not as fast as the horizon map is for whole-terrain updates (moving the light), which can be real-time with horizon maps, but the sun doesn't actually move that fast in reality anyway so it's fine I think.

I plan to support PSSM out of the box, it's the most common outdoor real-time shadowing option after all.