getHeight() on duplicated data.

I am using ODE with plsm2, and decided to make my own optimized getHeight() through my physics manager instead of through plsm2. So I capture the pagePreLoaded event, and copy the heightfield into my own array, then I use this duplicated height data to perform queries (this is a lot faster than using raySceneQueries, always operates on maximum LOD... which makes sense for physics. I duplicate the data so that I can run physics in a separate thread later.)

The problem is, that my getHeight() method does not return exactly the same height as a raySceneQuery on max LOD. Also, the shift seems to be bigger when querying for positions with big x/z numbers. So my question (finally): Is the heightfield somehow changed between the data one gets from pagePreLoaded and what is displayed on screen / data in the tiles? I have prodded around the sources, but cannot find anything obvious.

this is a lot faster than using raySceneQueries, always operates on maximum LOD
There is a flag to make plsm2 answer only at max LOD (therefore being faster.) But using separate thread it make sense to separate that.

Is the heightfield somehow changed between the data one gets from pagePreLoaded and what is displayed on screen / data in the tiles? I have prodded around the sources, but cannot find anything obvious.

All I can think of is the tile/page overlapping scheme : If a page is 257 it takes only 256 "grid cell space" as the goal is to make it join other page/tile seamlessly.
So try playing with you pagesize, pagesize - 1 to get correct height.

I am still having problems with this... Indeed, the big problem was that I divided with PageSize-1 instead of PageSize in my getHeight(). The thing is, I do not understand why this is wrong - in fact I think plsm2 is doing it wrong!

My pagesize is 513 and the x/y scale is 90,000, with 4x4 pages. When I place objects on the borders (at -180000, -180000), OgreOde asks for the position 0,0 , but the visible andscape starts much further in - it is smaller than OgreODEs landscape! If I change plsm2 to calculate scale.x and scale.y to 90000/512 instead of 90000/513, the size of terrain line up perfectly, but instead I have a gap of exactly one triangle between pages...

I thought scale.x would indicate the size of a triangle (90000/512) - what 90000/513 measures I do not know.

...could someone (tuan) help?

it is smaller than OgreODEs landscape
visually when you put your camera at expected boundary, you do not get terrain beneath ?

I have a gap of exactly one triangle between pages...
that's the triangle bewteen 513 and 512 you're missing there.

I thought scale.x would indicate the size of a triangle (90000/512) - what 90000/513 measures I do not know.
each page heightmap is 513, so between each point distance should be TerrainScale / page heightmap size => 90000/513 ?

No, there is a small difference (also with the camera... tricky to see exactly how much). Placing boxes I can see the difference is around two triangles. Two triangles difference is exactly the expected discrepance with four pages.

each page heightmap is 513, so between each point distance should be TerrainScale / page heightmap size => 90000/513 ?
But the edge vertices are the same as the ones one the bordering tile, right? So there are only 512 distances... so to speak.

Allright!!! I fixed it!
The problem was, indeed, in plsm2. The fix is to change lines 586 and 587 from OgrePagingLandscapeOptions.cpp into

scale.x /= PageSize -1;
scale.z /= PageSize -1;


and line 577 into:

const double scalemodif = 1;

... of course now ScaledPageSizeX is unnecessary, and we can use scale.x directly instead, but I quickfixed it in the above dirty way.

Tuan, do you want me to write a proper patch (getting rid of ScaledPageSizeX)?

I'll check that, thanks a lot !

it's in CVS.

Great!
And big thanks for maintaning plsm2 and OgreODE...