heightfield precision

I created a heightfieldShape constructor for use with the PLSM2. It basically takes an array of Reals that represent the height data. I have the heightfield samples defined as:

heightFieldDesc.samples = new NxU32[nbColumns * nbRows];
heightFieldDesc.sampleStride = sizeof(NxU32);


I use a char as an iterator, like in the samples, like this:

char* currentByte = (char*)heightFieldDesc.samples;

and then when filling out the samples, it's like this:

NxHeightFieldSample* currentSample = (NxHeightFieldSample*)currentByte;
currentSample->height = (NxI32)_height[row + column*nbRows];
currentByte += heightFieldDesc.sampleStride;


This works, except I'm getting some subtle precision issues. The heightfield doesn't exactly conform to the vertices. It seems like a precision issue, can you offer me any advice?

Seems like your converting it back to 8-bit rather than 16-bit. I'd loose the char and replace it with something else.

or perhaps it's because an NxHeightFieldSample's height member is an NxI16? It all gets converted to ints. I guess that's why the documentation says a heightfield reduces overhead. Guess I'll have to make a meshShape, eh?

I wouldn't use a meshShape for terrains, your going to have more overhead, and I would imagine the collision code is slow than terrain.

Have you tried scaling the Reals to a larger whole number say:


desiredHeight = height * totalHeight
...
mShapeDesc.heightScale = totalHeight


So it'll scale it back down again to a floating point number? Stick with the terrainShape, it's a lot better for terrains than the meshShape, and it works perfectly with the default Ogre Terrain. There isn't any reason why it won't work with PLSM2.

got it. I have it set up so that the level of precision control (the amount you scale / descale by) is independant for each tile. Furthermore you can have tiles within tiles, so that you can effectively determine a radius of PhysX tiles you want active around you. Because of the precision control, the greater the disparity between lowest&highest value in the tile, the less precise the heightfield. Right now a full tile from the PLSM2 has precision down to 0.01, so I think it should be OK

I'll work on serializing/paging next. Pretty cool throwing stuff around on the PLSM2

Fantastic! Any chance you can show some screen shots?

Very nice. That's with the "super-secret-edition" right?

no actually it's still Dagon code, because the PLSM2 gave me a hell of a time with Eihort. It shouldn't be all too difficult to port though

hey betajaen, have you looked at the mesh paging stuff at all? First off, they use an NxTriangleMeshShape instead of an NxHeightFieldShape. Secondly, it seems like it's designed to work for PhysX hardware, something I'm not particularly interested in just yet. Do you think perhaps I should write my own paging system for heightfieldShapes? It's just strategically loading cooked mesh files, right?

I've only read it briefly.

But I would go with your own solution. The mesh paging system seems to be more suited to GTA:SA (a lot of mesh shapes) than Oblivion (a lot of terrain and few meshes) which is the type we want.

is it possible even to cook heightfield shapes? meshShapes work because createTriangleMesh operates on an NxStream, which you can set as an in-memory buffer or a file. But neither createHeightField or NxHeightFieldDesc::samples seem suited to the task.

No, and that what puzzles me. However since it's not cooking, it must mean the shape code is fast.

There are a few solutions I have in my head about paging.

- Generate a super massive shape, with every single terrain page on it.

- Move the terrain bodies around when you move around. Streaming in a page would be equivalent of moving a static body from one side of the world to the other.

- Some how, modify the terrain shape in real-time, and update the shape heights to the current PLSM terrain.

this presents a serious hitch. I think it's going to be inefficient to keep the heightfieldShapes for the entire terrain loaded in memory. Maybe I should just write my own heightfield "serializer" which writes the samples data to the disk?

That'd work, but you couldn't directly save the shape class to disk. Just the initial terrain data, which is the image anyway.

I wonder, how much memory does a NxHeightfieldShape use anyway?

Perhaps you could recycle the shapes.

a quick search for "paging" in the ageia forums reveals that indeed their paging stuff is really a hardware feature. For a software implementation, they recommend you create your own system of buckets. I'm working on it now, and I think it's very beneficial to bypass the vertex fetching from the terrain and the scaling for the heightmap by saving the scaled samples to a file. I'm getting some weird errors, though. Do you know of any stipulations regarding the reading/writing of hundreds of files, each about 17k?

What about combing those files into a single file. Obviously keeping that file open would be much faster than opening and closing each separate file?

but, how can in nxogre use the heighmaps, and add a texture to it,, y use this but not works, the app goes down

mMundo = mScene->createStaticBody("terraine", "", new heightfieldShape("jeimap.png", 257,257,64,256,256));
//mMundo->mEntity->setMaterialName("terrenoTextura");


the first line works , and show a transparent but collide terrain, and the second, just go off the app

It's up to you to implement the heightmap visual code yourself. You should look how it's done in the Ogre Terrain demo.

Basically, it's just setting the world geometry.

Grom... it seems that you managed to use PLSM2 and Serialization work with NxOgre that's awsome!

I also need PLSM2 to work with NxOgre for my game, can you help me a little please if you've got some information ?

Thx a lot.

Ok in fact I'm able to get vertices and indexes for all my terrain tiles. Now what I'd like to know is:

1 - What's the best shape I could use to get a physic terrain (with vertices and indexes input)? It seems that only Convex shapes can handle vertices as parameters.
2 - Can I serialize those shapes on the disk in order to load it quickly?

Thx

1. ConvexShapes would be next to useless for Heightmaps. You want the a NxHeightField shape, the TerrainShape in NxOgre is an implementation of one.

2. Yes.