Dynamic heightfield with PhysX and Ogre 1.7

I don't really know how to start off my post so... hello.
Annnnyway, I did my fair share of searching before actually making a post, I think I have a bit of a problem asking for help.
But that aside, I noticed that everyone with any PhysX questions were usually told to come post here, so that's what I did!
If I'm wrong, kick me, I haven't slept much so I'm a bit braindead at the moment.

So down to business or whatever the terminology is... or phrase... whichever.
I'm trying to get a dynamic heightfield in place with PhysX and Ogre's new terrain system in 1.7.
I keep reading everywhere that people use what they refer to as a "tile approach", now I think I understand the basic concept...
Basically, divide the terrain into a bunch of smaller "tiled" heightfields then update them either through destroying and recreating them, or by preferably using the LoadFromDesc method since its said to be slightly faster.
Now this is all great, but I am totally at a loss where to begin.
For the past four days now I've been trying to find something that tells me how to go about "tiling" a PhysX heightfield, or just any heightfield in general, and I've been rather unsuccessful.
So seeing as how I've exhausted all my other pride-saving options, here I am asking for help, lol.

If you're too lazy to read my whole post:
1. I need help on creating a dynamic heightfield for use with Ogre 1.7 using PhysX (not NxOgre - I've played around with it quite a bit and its quite awesome but sadly it doesn't quite suite my needs at the moment).
2. From reading quite a bit about the subject of dynamic heightfields and PhysX I'm lead to belive that I have to use a "tiling approach" and I have no idea where to start.
3. Help me please.

Hello there,

I'm not so good with the Ogre part. I haven't used 1.7 yet, so it would be silly to give you some sort of guide in that area. What I will do, is teach you how to make a Heightfield system like in NxOgre.

Well first of all, you'll need a fileformat to store them in. Sadly; PhysX doesn't supply one like it does with the NxTriangle and NxConvex Meshes. Generally people just use images as the file and read them in; using red and green for heights and blue as a material index for each pixel. The problem is with that, you have extra converting to do, and you have the carry around an extra piece of code to read it, In NxOgre we use the "xhf" fileformat, and use shorts to save the height, tessellation and material index. Basically a NxHeightFieldSample. the advantage of this is, there's no conversion, you read it in, then you can directly give it into PhysX without a middleman.

The next step it to pre-load them in and keep them in memory, so you can use them at a whim. PhysX will store the master pointer for the NxHeightField for you, but doesn't provide a lookup system to fetch them later, so a std::map would be handy. I recommend roughly you'll need the following functions, and struct.

struct Heightfield
{

NxHeightField* heightfield; // The heightfield itself.
NxVec3 mSize; // Size of the heightfield (in metres). This could be embedded in your heightfield file, or from somewhere else
NxVec3 mCoords; // Coords of where the Heightfield would be. This could be embedded in your heightfield file, or from somewhere else.

// Make a NxHeightFieldShapeDesc from the heigthfield and params above.
void fillNxHeightfieldShapeDesc(NxHeightFieldDesc&);


// Static functions. You may want to have these in a central world/scene class.
static std::map<std::string, Heightfield*> gHeightFields;

static HeightField* createHeightField(const std::string& path*, const std::string& name);
static void releaseHeightField(const std::string& name);
static HeightField* getHeightField(const std::string& name);
};

Now you have to put them in the NxScene. You can decide to destroy/create them, or just have a grid of premade NxActors and swap the heightfields around. The above function "fillNxHeightfieldShapeDesc" in the struct will help you with both cases. I would go by the Ogre 1.7 terrain code to watch out what terrain pieces are being created/destroyed, so you can match up the differences in both scenes. I haven't use the Ogre 1.7 terrain code, so I can't tell you exactly what to do. But I imagine there is some monitoring class which you can use to detect when a heightfield is being created, so you can create one in PhysX and likewise when one is being destroyed.

Both of these functions may stress the solver a little. PhysX doesn't like static NxActors to be changed at all. So I recommend you freeze any NxActor on/over the heightfield whilst you do so; a trigger or sweepTest can help you there.

Personally, I would create the entire terrain at once, with every piece loaded in memory. Then turn off each section by disabling collisions for that particular NxActor, and any NxActor's associated with it; tree's, buildings, rocks, etc, then turn them back on, once the focus is back on them. It would far more memory, but would have no "lag" loading in heightfields in mid frame.

If you don't like that you could have a compromise, destroy HeightFields really far away that can't bee seen, turn off Heightfields that could be seen and may be focused upon.


But I think this is enough to get you started.

Thank you for that betajaen.

The main problem I'm having though, is figuring out how to achieve heightfield tiling, for example:

The reason for this is that it is currently the only way as far as I know that allows your heightfield to dynamically get altered with your dynamic terrain (for example the Ogre::terrain, ETM, etc.)
I don't know, maybe I need to get my head straight, I might just be missing the mark on this one.

Oh, and sorry for being so slow at replying, I'm a bit busy as of late.

Well each NxActor with one Heightfield would be a tile, the position of the NxActor would be in the exact x/z center of each tile, and the Heightfield's position would be -(halfWidth), -(halfDepth).

Unlike the visualisation, you'd always keep a hires of the tile running, otherwise the physics will be unstable (i.e. some NxActors will find themselves inside the heightfield, in low-resolution heightfields).

Alright, thanks a lot.

A quick question though...
Obviously as I understand it I have to use this method to be able to alter my heightfield dynamically.
I don't actually need deformable terrain in the game itself, I just want to use in the tool-set I'm busy creating because eventually it just makes things easier in the long run.
So once I actually start making a game, would you recommend still using "tiled heightfields" or simply stick to using a single heightfield?

Me? Would go with tiled heightfields. It allows switching "off" parts of the scene for optimisation purposes.

You? Stick with single height fields for now, but make your code open enough that implementing tiled isn't much of a problem if you find you need it later.

Lol, alrighty, thank you for your input and help.

I'm busy modifying the heightfield sample that comes with PhysX, its actually a bit easier than I originally thought.
Well, getting the heightfields to tile virtually seamlessly, now lets just see if I can get the whole modifying on the fly to work as it does in my head.
Lol, thanks again!

Could you post how to make a static heightfield of this terrain in ogre 1.7 on PhysX ?

Don't bump old threads.

Anyway, this thread, half way down from page 2. viewtopic.php?f=6&t=10859&start=15

sorry
but there are solution for a NxOgre
and i need solution for Physx SDK...