terrain lodding - strange effects ?

[Marc]

Hi !

I experimented with the landscape manager and had problems tweaking it in a way I want to. Then I tried to switch to wireframe to see what actually happens and I get renderings like this:



The different LOD levels seem to be distributed randomly somehow. That already wired but the most wired thing is, if I get closed to a quadratic patches, it's detail gets lower instead of higher!

Any idea what's wrong there? Is my assumtion wrong that the terrain lod method works like follows: "Split the whole terrain into quadratic blocks and set the lod level to draw depending on the distance to the camera." ?

That's the terrain.cfg I'm using:

Code: Select all

# The main world texture (if you wish the terrain manager to create a material for you)
WorldTexture=map1_TX.jpg

# The detail texture (if you wish the terrain manager to create a material for you)
DetailTexture=detailmap.jpg

#number of times the detail texture will tile in a terrain tile
DetailTile=256

# Heightmap source
PageSource=Heightmap

# Heightmap-source specific settings
Heightmap.image=map1_HF.raw

# If you use RAW, fill in the below too
# RAW-specific setting - size (horizontal/vertical)
Heightmap.raw.size=1025
# RAW-specific setting - bytes per pixel (1 = 8bit, 2=16bit)
Heightmap.raw.bpp=2
# Use this if you want to flip the terrain (eg Terragen exports raw upside down)
#Heightmap.flip=true

# How large is a page of tiles (in vertices)? Must be (2^n)+1
PageSize=1025

# How large is each tile? Must be (2^n)+1 and be smaller than PageSize
TileSize=65

# The maximum error allowed when determining which LOD to use
MaxPixelError=3

# The size of a terrain page, in world units
PageWorldX=1024
PageWorldZ=1024
# Maximum height of the terrain 
MaxHeight=100

# Upper LOD limit
MaxMipMapLevel=5

#VertexNormals=yes
#VertexColors=yes
#UseTriStrips=yes

# Use vertex program to morph LODs, if available
VertexProgramMorph=yes

# The proportional distance range at which the LOD morph starts to take effect
# This is as a proportion of the distance between the current LODs effective range,
# and the effective range of the next lower LOD
LODMorphStart=0.2

# This following section is for if you want to provide your own terrain shading routine
# Note that since you define your textures within the material this makes the 
# WorldTexture and DetailTexture settings redundant

# The name of the vertex program parameter you wish to bind the morph LOD factor to
# this is 0 when there is no adjustment (highest) to 1 when the morph takes it completely
# to the same position as the next lower LOD
# USE THIS IF YOU USE HIGH-LEVEL VERTEX PROGRAMS WITH LOD MORPHING
#MorphLODFactorParamName=morphFactor

# The index of the vertex program parameter you wish to bind the morph LOD factor to
# this is 0 when there is no adjustment (highest) to 1 when the morph takes it completely
# to the same position as the next lower LOD
# USE THIS IF YOU USE ASSEMBLER VERTEX PROGRAMS WITH LOD MORPHING
#MorphLODFactorParamIndex=4

# The name of the material you will define to shade the terrain
#CustomMaterialName=TestTerrainMaterial

[sinbad]

The LOD level is controlled by more than just distance - the 'roughness' of the terrain in a patch is also a factor. So flat areas will reduce far quicker than uneven areas. The roughness is determined based on the worst-case scenario for that patch, so if you have a pretty flat patch with a rough bit near the corner, that corner will dictate the LOD weighting for the entire patch.

[Marc]

Can I configure this somewhere? I guess you have to admit that the above tesselation is not desireable. It's still strange that the lod detail gets reduce when you get closed to something.

[tuan kuranes]

Can I configure this somewhere

reduce MaxPixelError. But you'll get higher LOD on all tiles.
You can modify that behaviour digging into TerrainRenderable.cpp Code, in the notifycamera() method.

I guess you have to admit that the above tesselation is not desireable

It's exaclty what's desirable !
Vertices count depends on complexity of tiles.
More Vertices on a flat plane doesn't give more visual informations, it just slow down the rendering.

[sinbad]

That already wired but the most wired thing is, if I get closed to a quadratic patches, it's detail gets lower instead of higher!

Are you using an old version? This used to happen in some cases back in 0.15 but the metric has been fixed since then, I've never seen it happen in 1.0.x and above.

[Marc]

It's exaclty what's desirable !
Vertices count depends on complexity of tiles.
More Vertices on a flat plane doesn't give more visual informations, it just slow down the rendering.

No, what is undesireable is the high lod levels in the distance. Even though they have sharp angels, you don't need such a high accuracy there. I think the weights of these two dependencies have to be adjusted in my case.

I started digging into TerrainRenderable and wondered about this line

Code: Select all

        Real D2 = delta * delta * C * C;

in void TerrainRenderable::_calculateMinLevelDist2( Real C )

Shouldn't there be a factor for the relation between level and distance? That formula only cares about the error you make by replacing one mesh with a lower detail mesh. But it does not respect that higher errors are less noticable at the distance. So I think it should be changed to something like this

Code: Select all

        Real D2 = delta * delta * C * C * level * level;

Another thing I looked at was the problem sinbad mentioned somewhere else, that the distance gets calculated wrong if you rotate the terrain scenenode. I think it gets fixed by doing

Code: Select all

                                Matrix4 xform;
		getWorldTransforms(&xform);
		
		Vector3 diff = xform * mCenter - cpos;

instead of

Code: Select all

		Vector3 diff = mCenter - cpos;

in void TerrainRenderable::_notifyCurrentCamera( Camera* cam ) .

[sinbad]

No, you've misunderstood calculateMinLevelDist2. It is calculating the world space difference between LOD levels (well, a view independent metric anyway), it should not be factoring in the actual LOD level into the metric since that's already part of the calculation above. This world space difference is then used to calculate a screen space difference in realtime which determines which LOD to use. The metric just explains how much 'different' the LODs are, it should make no reference at all to distance (it is used with a distance calculation, not derived from it).

If you want an explanation of this, TSM is a direct implementation of de Boer's technique: http://www.flipcode.com/articles/article_geomipmaps.pdf

Your problems may well be because you're shifting the terrain around manually, which I never do and isn't officially supported at present. Patches welcome, but the terrain is typically the 'root' of the scene anyway, you should orient everything else according to it rather than vice versa.

[Marc]

Ok It read that paper. I think there is a small thing that might have to get changed. It's not stated clearly in the paper but: The assumption is that there is a maximum error tolerance. If you exchange a patch with another that has a higher error value in screenspace than the maximum error tolerance, then the user will notice this and this has to be avoided. But as far as I understand the current implementation, it does something else: It checks if the error in screenspace between the new lod level and the highest lod level is smaller than the allowed maximum. That's a difference! In version 1, the error is allowed to accumulate, thus allowing a multiple of the specified maximum error tolerance compared to the highest resolution mesh. Therefore, version 1 would produce lower triangle count while the assumption of the maximum error tolerance is still hold.

(My suggestion to add level * level has somehow the same effect because it simulates the accumulation of the allowed error in relation to the highest resolution mesh. However, the comparison mesh by mesh is more correct.)