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:
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:
- The entire terrain area is PageSize x PageSize vertices large. These vertices are stretched over the Ogre units using terrainInfo.setExtents().[/*:m]
- 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]
- 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