Daerst
27-05-2009 17:28:54
Hi there,
I tried to modify NxOgre Tutorial 2 (cube falling on a plane) to use a terrain instead.
I removed the plain, added an Ogre terrain - the basic thing from the samples.
I then converted it into a .xhf-file using Flour.
ResourceSystem::getSingleton()->openArchive("media", "file:D:/OgreSDK/media/");
HeightField* hg = HeightFieldManager::getSingleton()->load("media:terrain.xhf");
HeightFieldGeometry* hfg = new HeightFieldGeometry(hg, Real3(1000,10,1000));
mScene->createSceneGeometry(hfg);
Although I let the cube start way above the terrain (y=100 or something) it just falls through.
Alright, maybe the physical terrain just hangs around somewhere else - I wanted to check that using the visual debugger, so took the whole thing over to NxOgre Tutorial 3 (cube falling on a plane, with visual debugger).
Problem: after 2 minutes of doing nothing the application gives me an "out of video memory" message O_O
I tried the same thing out with BloodyCake later. Works all fine until I press the "Visual Debugger" button - hangs, does nothing, throws exceptions.
a) Am I doing something wrong? Maybe my xhf file is foul?
b) If I can't get that debugger thing to work I'd really like to know where the terrain is created by ceateSceneGeometry
Thanks
Daerst
spacegaier
27-05-2009 18:03:09
Allright. Since the 1.5.4 there is a little bug in the terrain system (some flipped axis). Either case, Terrain and VisualDebugger is really slow (however helpfull at the beginning). Your code seems right, so could be the XHF file.
Could you explain your VisualDebugger problem a bit more? Any error messages? Did you excatly proceed as described in the tutorial?
Concerning the memory problem? Could it be that you are endless adding some actors or such to the scene?
Daerst
27-05-2009 18:19:40
The standard terrain is 513x513px. I tried it with 129x129 and voilĂ it works, but very very VERY slow - and looks quite odd.
So I guess the debugger error was really what it claimed to be - too much load for the graphics card.
Which leads directly to the terrain problem itself
ResourceSystem::getSingleton()->openArchive("media", "file:D:/OgreSDK/media/");
HeightField* hf = HeightFieldManager::getSingleton()->load("media:terrain.xhf");
HeightFieldGeometry* hfg = new HeightFieldGeometry(hf, Real3(10,1,10));
hfg->setTerrainCentering(Enums::TerrainCentering_CenterAbove);
mScene->createSceneGeometry(hfg);
Ouch. Any idea? What was that about the flipped axis?
Thanks for your help so far!
betajaen
27-05-2009 18:56:22
Unfortantly there is a known bug in 1.5.4 concerning the heightfields. In short; I mixed up "y" and "z". I can give you the fix here if you like, as 1.5.5 is going to be a while.
Daerst
27-05-2009 18:58:26
That would be great, thank you
betajaen
27-05-2009 19:01:16
The constructor in "NxOgreHeightFieldGeometry.cpp" should be;
HeightFieldGeometry::HeightFieldGeometry(HeightField* heightfield, const Vec3& size)
: Shape(0), mHeightField(0), mHeightFieldShape(0)
{
HeightFieldGeometryBlueprint* blueprint = static_cast<HeightFieldGeometryBlueprint*>(mBlueprint);
blueprint->mHeightField = heightfield;
blueprint->mSize.x = size.x / Real(blueprint->mHeightField->getHeightField()->getNbRows());
blueprint->mSize.y = size.y / 32768.0f;
blueprint->mSize.z = size.z / Real(blueprint->mHeightField->getHeightField()->getNbColumns());
blueprint->mTerrainCentering = Enums::TerrainCentering_LocalPose;
blueprint->mSmoothSphereCollisions;
blueprint->mHoleMaterial = 65535;
blueprint->mHighBits = 0;
}
You'll notice in your source code. y and z are the wrong way around.
Scroll down a bit, then find something like this;
heightfield->rowScale = blueprint->mSize.x;
heightfield->heightScale = blueprint->mSize.y;
heightfield->columnScale = blueprint->mSize.z;
Make sure it looks like that. Y is height remember, not length.
Daerst
28-05-2009 16:45:56
So, my physical heightfield is there and I can see it (because it's small enough to not eat up all my memory) using the debugger.
But I'm still struggling with the positioning. Is this all I have to do?:
hfg->setTerrainCentering(Enums::TerrainCentering_CenterAbove);
Because for me it's no change whether I remove the "setTerrainCentering" line, set it to TerrainCentering_CenterAbove or TerrainCentering_CenterXZ. The physical terrain is always from zero in positive X- and Z-direction and in the Y direction a bit above, but also far below zero - where it shouldn't be when using CenterAbove, right?
What am I missing?
//EDIT:
hfg->setLocalPose(NxOgre::Matrix44(Real3(0,100,0)));
Alright, I am able to move the terrain now. This is what my terrain.cfg says:
PageWorldX=100
PageWorldZ=100
MaxHeight=100
Setting y=100 for the physical terrain scale is way too much though. y=50 is better.
In addition the terrain is somehow mirrored (X and Z swapped?)... Gonna check NxOgreHeightFieldGeometry.cpp again.
//EDIT2:
My NxOgreHeightFieldGeometry.cpp is alright. Maybe there is a rows/cols mixup in NxOgreManualHeightField.cpp or somewhere? Or a mixup in Flour? Or a mixup in my own brain and I did something wrong?
//EDIT3:
I just flipped the heightfield image so it basically fits (temporary solution
) and played around with the position and scale.
Scale 100x100 doesn't fit that well. I approached it with about 103.15. Y scale is difficult too. Unsatisfactory
Isn't there a way to _really_ fit the NxOgre terrain onto the Ogre terrain?
Daerst
07-06-2009 18:44:26
Any new discoveries concerning NxOgre heightfields?
spacegaier
14-06-2009 21:27:27
Yes, that the patch above posted by betajaen doesn't work as it is there for two reasons:
1. It uses Vec3 which isn't in 1.5.4 (it's a new NxOgre Vector format of the newly written math functions). Just replace it with Real3.
2. Using Shape(0) results in a runtime error. Replace it with Shape(new HeightFieldGeometryBlueprint()) as it was in the old version.
So that's what it should look like:
HeightFieldGeometry::HeightFieldGeometry(HeightField* heightfield, const Real3& size)
: Shape(new HeightFieldGeometryBlueprint()), mHeightField(0), mHeightFieldShape(0)
{
HeightFieldGeometryBlueprint* blueprint = static_cast<HeightFieldGeometryBlueprint*>(mBlueprint);
blueprint->mHeightField = heightfield;
blueprint->mSize.x = size.x / Real(blueprint->mHeightField->getHeightField()->getNbRows());
blueprint->mSize.y = size.y / 32768.0f;
blueprint->mSize.z = size.z / Real(blueprint->mHeightField->getHeightField()->getNbColumns());
blueprint->mTerrainCentering = Enums::TerrainCentering_LocalPose;
blueprint->mSmoothSphereCollisions;
blueprint->mHoleMaterial = 65535;
blueprint->mHighBits = 0;
}
dreamer
14-06-2009 23:41:02
I'v tryed, found that y=MaxHeight/2 is perfect, but the scale is difficult to fit, they changed according to the "PageWorldX" and "PageworldY" in the terrain.cfg, why? and how to set them?
dreamer
15-06-2009 04:02:33
Right, there is a rows/cols mixup somewhere. I'm trying to correct it. Is there anybody know how to correct? please tell me!
ethan
03-07-2009 00:41:01
I confirm the patch above doesn't seem to work.
I've tried and I still have the same problem.. wrong axis.
Anyone has a solution?
spacegaier
03-07-2009 08:25:13
The patch above works like a charm and btw there is a new BloodyMess version out there (1.5.5) that has it in, so need to patch this manually anymore.
If it still persists, you could load up your XHF file so that we can check whether it is valid.
ethan
03-07-2009 16:50:32
I tested with new 1.5.5, it seems to work perfectly now but there isn't any visual debugger so I can't see my terrain.
spacegaier
03-07-2009 17:56:36
Yes, the VisualDebugger was switched off in 1.5.5 as a rewrite of the DebugRenderables is in progress, but not finished -> doesn't work right now.
But you can use the RemoteDebugger of PhysX (in the bin folder of the PhysX SDL folder).
Just add these two lines and make sure that you start the RemoteDebugger before you start your app.
NxOgre::RemoteDebugger *pRD = m_pWorld->getRemoteDebugger();
pRD->connect();
ethan
03-07-2009 21:57:51
I don't know how it works but it works!
thks for the advice. Now I'm going to use this remote debugger.
I still need to find a way to make the heightfield loaded in Ogre look the same as the heightfield loaded by NxOgre because they absolutely look different and I don't know why!
I'm looking forward for your tutorial on heightfield..
betajaen
03-07-2009 22:33:31
Let's have a butchers at your heightfield them, a screenshot of the VRD will do nicely.
ethan
04-07-2009 15:02:03
here it is:
As we can see the heightfield loaded by Ogre is just above the heightfield loaded in NxOgre.
The barrel on the ogre picture has been droped at the bottom of the small valley
I think this is just a simple trick to make the both exactly look the same.
Any advice is welcome!