Bobf
10-05-2007 03:02:22
Using latest CVS of PLSM2 and Ogre 1.4.0 SDK, i've finally managed to get the terrain running in my application with collision physics (a bit too memory intensive for my liking at the moment).
The first problem is with LoadNow.. I get proper physics detail, but the landscape renders at some absymal LOD. If I skip loadnow this doesn't happen, but i'd prefer to load the terrain in one chunk to begin with. Subsequent calls to loadnow crash the application.
The second and worst problem is upon calling
setOption( "LoadMap", 0 )
even if I don't physically change the map, only the texture (via the demo application's code) the terrain never appears.
The physics data still remains(wiki ogrenewt physicsmanager implementation) <- maybe i'm not destroying it? or the map is loading and i need to somehow update it.
is this all that is required to load a map? following the demo application was a bit difficult for me. I'll study it some more when i get the chance.
the logs reveal nothing.
ps.
void PagingLandScapeOctreeSceneManager::clearScene(void)
seems to crash when i add an input handler(in my own program) upon exit? (probably destroying things in the wrong order and its just picking up here randomly)
side questions:
other than these hiccups, the terrain is quite good. does anyone have a slightly better idea for physics collision with the terrain? Outputting 200mb of collision data takes too long to load in (aswell as the size).. not quite sure on a solution here.
maybe with background feeding mesh to newton. or collision mesh LOD.
even if you do feed this information to newton, it's still 200mb of ram.
though its possible even half-life 2 had this problem, the loadtimes were not particularly great and quite common. No idea on how farcry did it, though I can't quite remember the requirements for it.
edit: ogrenewt was (and still is, causing the majority of the issues it seems)
The first problem is with LoadNow.. I get proper physics detail, but the landscape renders at some absymal LOD. If I skip loadnow this doesn't happen, but i'd prefer to load the terrain in one chunk to begin with. Subsequent calls to loadnow crash the application.
The second and worst problem is upon calling
setOption( "LoadMap", 0 )
even if I don't physically change the map, only the texture (via the demo application's code) the terrain never appears.
The physics data still remains(wiki ogrenewt physicsmanager implementation) <- maybe i'm not destroying it? or the map is loading and i need to somehow update it.
String nextMap, currentMap;
String nextTexture, CurrentTexture;
sceneMgr->getOption( "CurrentMap", ¤tMap );
if(sceneMgr->getOption( "NextMap", &nextMap ))
{
if (nextMap != currentMap)
{
sceneMgr->setOption( "CurrentMap", &nextMap );
sceneMgr->getOption( "CurrentTexture", &CurrentTexture );
}
}
sceneMgr->setOption( "LoadMap", 0 );
is this all that is required to load a map? following the demo application was a bit difficult for me. I'll study it some more when i get the chance.
the logs reveal nothing.
ps.
void PagingLandScapeOctreeSceneManager::clearScene(void)
seems to crash when i add an input handler(in my own program) upon exit? (probably destroying things in the wrong order and its just picking up here randomly)
side questions:
other than these hiccups, the terrain is quite good. does anyone have a slightly better idea for physics collision with the terrain? Outputting 200mb of collision data takes too long to load in (aswell as the size).. not quite sure on a solution here.
maybe with background feeding mesh to newton. or collision mesh LOD.
even if you do feed this information to newton, it's still 200mb of ram.
though its possible even half-life 2 had this problem, the loadtimes were not particularly great and quite common. No idea on how farcry did it, though I can't quite remember the requirements for it.
edit: ogrenewt was (and still is, causing the majority of the issues it seems)