[help] Deformation problems/bugs

jguerra

15-10-2007 16:28:17

After 2 weeks trying to solve the problem that has been haunting me (http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=5323), i've put on hold this issue so i could move on and start implementing some other functionalities of the project i'm in. I'll be back to this problem sooner or later, so i'm hoping that someone can help me during this time.
I'm going to try to write down all the problems i've encountered and give enough detail to enable you to help me.

So, here it goes.




As you can see from the above image, the deformation tool is opening up "holes" by "stretching" some vertex (within or around the area of deformation) to the position (0,0,0) (these coordinates are my assumption, i've not tested to see if this is correct) of the page they belong to. If more than one page is deformed the several vertex have the same behavior, "stretching" to the position (0,0,0) of their own page.
Adjusting the number of pages and the number of tiles each page has, i've come to the conclusion that the "stretching" only happened when the deformation was made using 2 or more tiles. Coming to this "not so satisfying" solution, but usable solution, i've started testing some of the tools i've created using only 1 page and 1 tile per page. But... suddenly the same problem came up, but this time it was driven by the size of the brush....
When the size of the brush was greater than 6 everything worked fine, when it was below or equal to 6 the problem appeared... After tweeking with some .cfg options i've realized that the option that was making it deform well above the size of 6 was vertexProgramMorph=yes. If i turned it off, it would only work with a size around 25 or above (haven't figured out what was the exact value).
(see image below)




After that, i started messing around with some .cfg options and found out some different results.

If i use the .cfg option VertexCompression=yes the behavior differs a little. Instead of the "stretching" to the position (0,0,0), it "stretches" some vertices of a *row* which width corresponds to the size of the deformation brush and stretches them to the maximum height.
When testing this new behavior I also found out that this also happened when i tried to deform too close to the edges of the terrain that are parallel to the *row* badly deformed or when the height limit is reached.
(see image below)



When i change de .cfg option MaxPixelError (in this case it's set at 5) it creates an unusual behavior that changes the terrain erroneous deformation up and down has i zoom the camera in and out.
(see images below)




Another strange behavior is when i use setHeightCenter instead of DeformationCenter. Although the heightmap is correctly modified, the visible deformation is always the same (depression) even when i provide positive or negative values to the brush array.

setHeightCenter code:

mSceneMgr->setOption("BrushArrayWidth",&mDeformBrushWidth);
mSceneMgr->setOption("BrushArrayHeight",&mDeformBrushHeight);

Ogre::Real mDeltaArray[mDeformBrushWidth * mDeformBrushHeight];
mSceneMgr->setOption("BrushArray", mDeltaArray);
mSceneMgr->setOption("fillBrushArray", &point);

for(Ogre::uint i=0;i<mDeformBrushWidth*mDeformBrushHeight;i++)
{
mDeltaArray[i]-=20;

std::cout<<"->"<<mDeltaArray[i]<<std::endl;
}

mSceneMgr->setOption("setHeightCenter", &point);


Although these strange deformations happen in real-time, the heightmaps are always stored correctly. So, when i restart the program, the terrain assumes the correct heights.
After exhausting all the alternatives (or at least most of them) i could think of, i dove into the PLSM2 code having in mind the fact that the heightmaps were correctly stored and loaded, so i changed the PageUpdate option to unload and load the given page. And it worked, the terrain deformation works well... The only problem is that the real-time deformation is lost, and that is not acceptable for what we want to do.
During the time i spent trying to solve this problem and inspired by another post i found here about some normals issue, i forced a whole terrain deformation (with the minimum brush scale possible) after applying the deformation brush, and this worked, the terrain regained the correct shape. Although visually this is a lot smoother than the unload/load of a page it's still not acceptable.

As you can see on the first set of images, the outlines of the pages are also visible....

DeformationCenter code:
mSceneMgr->setOption("BrushSize",&mDeformBrushWidth);
mSceneMgr->setOption("BrushScale", &mBrushScale);
mSceneMgr->setOption("DeformationCenter", &point);


hf_129_3.gen.cfg

GroupName=PLSM2

LandScapeFileName=hf129_3
TextureStretchFactor=1


OutDirectory=LandScapeFileName

PageSize=129

HeightMap=yes

MiniMap=yes
MiniMapWidth=64
MiniMapHeight=64

BaseMap=yes
CoverageMap=yes
AlphaMaps=yes

LightMap=yes
Sunx=0.0f
Suny=0.88f
Sunz=0.47f
Ambient=0.5f
Diffuse=0.5f
Blur=0.0f

ZHorizon=yes


NumMatHeightSplat=4

MaterialHeight1=30
MaterialHeight2=60
MaterialHeight3=100

SplatFilename0=splatting_sand.png
SplatFilename1=splatting_grass.png
SplatFilename2=splatting_rock.png
SplatFilename3=splatting_snow.png


hf_129_3.cfg

GroupName=PLSM2

Width=2
Height=2

TextureStretchFactor=1

LandScapeFileName=hf129_3
FileSystem=LandScapeFileName

NumTextureFormatSupported=14

TextureFormatSupported0=Base
TextureFormatSupported1=Base2
TextureFormatSupported2=InstantBase
TextureFormatSupported3=Splatting
TextureFormatSupported4=Splatting2
TextureFormatSupported5=Splatting4
TextureFormatSupported6=Splatting6
TextureFormatSupported7=Splatting7
TextureFormatSupported8=Base
TextureFormatSupported9=Base2
TextureFormatSupported10=Splatting3
TextureFormatSupported11=Splatting5
TextureFormatSupported12=SplattingShader
TextureFormatSupported13=InstantBaseShadowed

TextureFormat=SplattingShader

PageSize=129
TileSize=65

ScaleX=1500
ScaleY=300
ScaleZ=1500

#VisibleRenderables=256
CameraThreshold=5

MaterialHeight1=5
MaterialHeight2=95

NumMatHeightSplat=4

AvgColorsExists=yes

#Sand
MaterialColor0=1.0f 1.0f 0.0f 1.0f
#Grass
MaterialColor1=0.13f 0.545f 0.13f 1.0f
#Rock
MaterialColor2=0.411764f 0.411764f 0.411764f 1.0f
#Snow
MaterialColor3=1.0f 0.98f 0.98f 1.0f

SplatFilename0=splatting_snow.png
SplatFilename1=splatting_rock.png
SplatFilename2=splatting_grass.png
SplatFilename3=splatting_sand.png


# where to put camera on load.
BaseCameraViewpoint.x=-4098.0f
BaseCameraViewpoint.y=30644.0f
BaseCameraViewpoint.z=293.0f

Baselookat.x=0.0f
Baselookat.y=0.0f
Baselookat.z=0.0f

##ADDED
Deformable=yes
TextureModifiable=yes
VertexProgramMorph=yes
VertexCompression=yes
MaxPixelError=5


As you can see i'm using the supplied terrain hf129_3 scaled to twice the size. (257x257)
I'm using Gentoo, Ogre 1.4.4 and CVS PLSM2. Also, the graphical card is a NVidia 7600 GT.

Any help is welcome.
Thanks in advance.

tuan kuranes

15-10-2007 17:57:50

You can Use nvperhud to read the vertex buffer content before and after update to find the spot where buffer is wrong.

Strange that bugs only happens on linux ?
if it works on same machine win32 gl and dx ?... I'll go for a driver bug.

Anyway code you should read is in paginglandscaperenderable.cpp where it load content in buffer.

Check condition of bug and if partial Vertex Buffer is enabled and seems the case, disable it.

My guess is that the driver doesn't handle well partial Vertex Buffer update.