getOption usage (nr. of tiles) & general PLSM confusion

pra

14-06-2007 10:59:48

hi there,

i want to use plsm2 with ogrenewt, and because calculating collision on tile load is goddamn slow, i want export the collision of the tiles and load it then necessary. To do so, i wanted to loop through all tiles first and do something similar to the tileLoaded function from the wiki. To get the total number of tiles, I thought i should use getOption with "getAreaSize", but i can't figure out what kind of second param i have to pass and how i'm supposed to use it. the wiki article lists the key strings, but not how to use the results.

Question 1: is this approach right? if not, how to get the number of tiles?

Question 2: what exactly is a "tile"? I think a "page" is made of a file like "alpes.0.1.png", would mean Alpes has 6 pages. A page seems to be subdivided in tiles, but how small is a tile?

Question 3: when should i remove(hide/disable) my custom game content? when the tile it's standing on is unloaded? when the page is unloaded? never?

Jon

14-06-2007 17:18:15

I haven't worked with OgreNewt, so I can't say whether your approach is the best or not. Precalculating the data does sound reasonable.

First, let us address the definitions of page and tile. There is not much hope in doing anything beforehand.

The unsplit heightmap is split into pages by mapsplitter. One specifies the page size in the mapsplitter configuration file (2^n+1).

Pages are subdivided into tiles internally, a tile is the smallest renderable. The tile sizes are also specified in the map splitter configuration file.

A typical size for each of these is 513 for the page size and 65 for the tile size. Pages and tiles overlap.

A 4kx2k map (Grand Canyon for instance) would be made up of 8 pages in the X direction and 4 pages in the Z direction, for a total of 32 pages.
Each of the pages would then be made up of 8x8 or 64 tiles.

A page is the smallest loadable unit.

getAreaSize takes an array of four points and calculates the area of the rectangle. This is not what you want.

One way to get the map size is through the PagingLandScapeOptions object. Calling PagingLandScapeSceneManager::getOptions returns a pointer to this object.

Height and Width give the map dimensions in pages. An example of extracting a value:


int height;
options -> getOption("Height", &height);


As for question #3, I have no opinion.

pra

14-06-2007 21:09:57

ok, that was very helpful, thx but but i still have questions:
the wiki example does the following to retrieve vertex data on tile load:

std::vector<void*> params;
int renderLevel=0;
params.push_back(&pageX);
params.push_back(&pageZ);
params.push_back(&tileX);
params.push_back(&tileZ);
params.push_back(&renderLevel);
mSceneMgr->getOption("PageGetTileVertexData_2",&params);


* [0](Ogre::uint*) = X Index of the Page to retrieve data from,
* [1](Ogre::uint*) = Z Index of the Page to retrieve data from;
* [2](Ogre::uint*) = X Index of the Tile within the Page to retrieve data from,
* [3](Ogre::uint*) = Z Index of the Tile within the Page to retrieve data from,
* [4](Ogre::uint*) = LodLevel to get the data at (note that level 0 means highest detail)

i'm a little confused now, if tiles and pages overlap (i understood it like a tile can be half in page0_1 and half in page1_1), why does this function requre the tile relative to a page?

I also guess additional to the size in pages I need to retrieve the size of a page and of a tile of the current terrain in order to use this function (calculate nr of pages and tiles in a page, then loop through them). Can I do this?

Jon

14-06-2007 22:39:57

The overlap is one pixel on each axis. You can pretend there is no overlap for things like PageGetTileVertexData. I just didn't want to avoid mentioning it.

The PagingLandScapeOptions object has both tile size and page size as public members.

pra

17-06-2007 17:53:36

options -> getOption("Height", &height);
if I do this, VC++ gives me a linking error:

error LNK2001: unresolved external symbol "public: bool __thiscall Ogre::PagingLandScapeOptions::getOption(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,void *)" (?getOption@PagingLandScapeOptions@Ogre@@QAE_NABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PAX@Z)


i tried this instead:
mLog("height="+str(opt->world_height));
mLog("width="+str(opt->world_width));

here the output:
18:47:39: PRA: height=3
18:47:39: PRA: width=2
seems to work, too...

pra

21-06-2007 13:12:00

one more thing:
the options object contains the variables NumTiles and NumPages.
did i understand it right that NumPages contains the overall nr. of pages (width*height) while NumTiles^2 = nr. of tiles within a page?

i think this should be explained somewhere


PS: my VC++ won't autocomplete anything PLSM2 related. it also says "symbol undefined" when i rightclick "PagingLandScapeSceneManager" or similar and do "go to definition". any idea why?

Dibalo

21-06-2007 17:26:41

I got the same problem when using OgreNewt. BUT! You can use NxOgre. It´s very powerful and very easy to integrate with PLSM2. An the best: there is no need pre-create collision data. You can handle your physics data at runtime! ( I use 2k maps and working well ;) )

pra

21-06-2007 20:57:43

ooook, my code actually works, BUT:
it seems in debug mode the members of the option object are all invalid.
this code:
mLog("TileSize="+str(opt->TileSize));
mLog("PageSize="+str(opt->PageSize));
mLog("NumTiles="+str(opt->NumTiles));
mLog("NumPages="+str(opt->NumPages));
mLog("height="+str(opt->world_height));
mLog("width="+str(opt->world_width));

gives this output in release:
21:47:27: PRA: TileSize=65
21:47:27: PRA: PageSize=513
21:47:27: PRA: NumTiles=8
21:47:27: PRA: NumPages=6
21:47:27: PRA: height=3
21:47:27: PRA: width=2

and this in debug:
21:56:39: PRA: TileSize=7536737
21:56:39: PRA: PageSize=2097253
21:56:39: PRA: NumTiles=7602273
21:56:39: PRA: NumPages=7471215
21:56:39: PRA: height=7274528
21:56:39: PRA: width=7602293

is this a bug?

pitmodano12

30-08-2007 08:46:04

Good day!
I think the problem is not so big. Wow this topic is moving fast today!