Beginner questions; rounding on posToVertex()

helgridly

26-07-2009 11:57:03

Hi all,

I'm trying to get my head around ETM and terrain management in general. I have a few questions just to make sure my understanding of the system is accurate, and one marginally more complicated question.

The way I understand Ogre/ETM terrains is like this:
  1. The entire terrain area is PageSize x PageSize vertices large. These vertices are stretched over the Ogre units using terrainInfo.setExtents().[/*:m]
  2. The terrain area is subdivided into smaller areas called Tiles. These have no effect on the terrain itself, only on the textures applied, since LOD texture swapping is applied on a per-tile basis.[/*:m]
  3. The arrangement of the vertices over the terrain is in a square pattern, not triangles.[/*:m][/list:u]
    Is this understanding correct?

    My second question: if you fire up the sample app and use a 1x1 brush on a very coarse (9x9) terrain and go to each corner in turn you'll find that you can't raise the cornermost vertex on all corners. This, at first sight, appears to be a bug, in that the posToVertex() functions aren't accurately picking the closest vertex to the Ogre point passed in.

    Assuming you can't have negatively numbered vertices, I would have thought that posToVertexX() should be defined as follows, in order to pick the actual nearest vertex to the Ogre position:
    int posToVertexX(float x) const { return (int) (((x-mOffset.x)/mScale.x) + 0.5f); }
    And similarly for Z. It would, however, be presumptuous of me to assume this is a genuine mistake and not done deliberately. So instead I ask: for what reason doesn't it round?

    Cheers :)