From: Jack P. <ch...@gm...> - 2007-03-24 21:31:42
|
Small update on nCTerrain2 : it really looks like it has issues with multithreading. Setting nChunkLodNode and nTextureQuadTree NOT to use asyncronous load prevents application from crashes, and renders terrain smoothly (without texture at this moment, however I suppose that will be resolved by working on shaders/configs). By the way, I have REAL multithreading (dual-core Intel Core 2 Duo CPU), may be that has smth. to do with the problem. Once again, any information on this topic will be highly appreciated. 2007/3/24, Jack Popovciuc <ch...@gm...>: > > Hi all, > > There are: > nCTerrain2 - which looks like was used by RadonLabs in their SDK, > nCLODTerrain - another implementation of CLOD terrain? > nMap - ? > > It looks like all of them are unmaintained for a some time > None of them compiled for me from the start (I use Visual Studio 2005). > After I spent some time on configuration, then a couple of days of debugging > and resource files manipulations, I managed to run them. > > However, only nMap displays something and does not crush. > > nCLODTerrain demo shows wheels, which fall on something invisible (should > be terrain, I suppose), but it is not rendered. And after some time crashes > with DX E_OUTOFMEMORY error on creating empty small-size texture > (D3D9Texture->CreateEmpty()). The program itself consumes less than 10Mb of > RAM at that moment... > > ncTerrain2 had a bug with not initializing terrainScale (it was a random > huge number), then a probably bug with incorrect logic on asserting empty > mesh state (it supposed to be Valid after creating an empty mesh). After a > couple of days of struggling I managed to run it finaly, and a couple of > times it even displayed smth. like untextured terrain. Then I started to > play with size/scale, and now I am constantly receive E_OUTOFMEMORY from > nChunkLODMesh::CreateVertexBuffer() (which is > nD3D9Mesh::CreateVertexBuffer()), or from CreateEmptyTexture(), although > program consumes less than 10Mb of memory, and buffers supposed to be > created are of reasonable size. Not sure if it is significant, but all > the calls in these failing cases are made by ResourseServer from a separate > thread. > > If someone can explain current status of these project, or give a clue on > why this error appears, please do not hesitate to do that! Any information > will be appreciated. > > Jack. > > > |