Page 3 of 3
Posted: Sun Apr 18, 2010 9:02 pm
by Alastriona
hybrid wrote:Larger sizes should work as expected, I did work with huge terrains some time ago. Was just to make sure that it's not the problems here.
I didn't check any of the code for real, just checking with my eyes. No more time for anything else, sorry. Also no time for the debugging of the terrain node yet. Moreover, it's probably a windows only problem...
Well all my issues seem to be resolved now, so thanks for all the time you put into answering my questions. Including some of the more stupid ones
. And yeah trying some larger sizes for fun. My first attempt at 10001x10001 made me run out of memory. Seems up to 2000x2000 is fine. with 3000x3000 I was up to using about 1.5 gigs
.
@bonsalty
What is the issue you are describing? Are you saying that multiple calls of RAWloader will leak memory?
Posted: Sun Apr 18, 2010 9:57 pm
by bonsalty
"The moral of the story" - If a code works on one machine but not on the other - its a bug or its your fault
. Your code with the "char version" isnt working . Lets take a float pointer.
Code: Select all
float* lpBits = (float*)malloc(129*129*sizeof(float));
for(u32 t = 0; t < 129*129; ++t){
lpBits[t] = rand() % 20;
}
io::IReadFile * filem=params->device->getFileSystem()->
createMemoryReadFile (lpBits, 129*129*sizeof(float) , "heightmap");
terrain = params->smgr->addTerrainSceneNode(
NULL,
NULL, // parent node
-1, // node id
core::vector3df(0, 0, 0), // position
core::vector3df(0, 0, 0), // rotation
core::vector3df(1,1,1), // scale
video::SColor ( 255, 255, 255, 255 ), // vertexColor
3, // maxLOD
scene::ETPS_65, // patchSize
0 // smoothFactor
);
terrain->loadHeightMapRAW(filem,32,true);
The code seems ok
This is not Ok.
Unhandled exception at 0x00661eff in OpenGLDialog.exe: 0xC0000005: Access violation reading location 0x00000000.
->loadHeightMapRAW(filem,32,true);
The same with char. I dont know if this works in XP whatever, it doesnt in Windows7
This is not the first thing that fails in this microsoft peace of sh*t. Its so good to blame them... Or maybe we are menthal nudists, its the other option.
Posted: Sun Apr 18, 2010 10:08 pm
by bonsalty
Alastriona:
Check out my post about camera movement, render+ terrain node. I posted a simple code.
I have a wrapper class for irrlicht. I use it for animating surfaces with terrainscenenode. Your option for animation is to remove the node, create a new one, remove, create, etc. Or you use the RawLoader, (I dont think its relevant faster maybe better??!
). What I have seen is, when I move the camera meanwhile, the memory usage starts growing like cancer. If the camera is fix, everything is ok.
Posted: Sun Apr 18, 2010 10:23 pm
by Alastriona
bonsalty wrote:"The moral of the story" - If a code works on one machine but not on the other - its a bug or its your fault
. Your code with the "char version" isnt working . Lets take a float pointer.
The code seems ok
This is not Ok.
Unhandled exception at 0x00661eff in OpenGLDialog.exe: 0xC0000005: Access violation reading location 0x00000000.
->loadHeightMapRAW(filem,32,true);
The same with char. I dont know if this works in XP whatever, it doesnt in Windows7
This is not the first thing that fails in this microsoft peace of sh*t. Its so good to blame them... Or maybe we are menthal nudists, its the other option.
Acki is using WinXP and minGW. I'm using WinVista and MSVS2008. The same bit of code gave me access violations as well. compiling irrlicht myself fixed it for me.
What compiler are you using? And are you using the precompiled version of Irrlicht or did you compile it yourself?
Posted: Sun Apr 18, 2010 10:49 pm
by Acki
Alastriona wrote:Acki is using WinXP and minGW.
...
And are you using the precompiled version of Irrlicht or did you compile it yourself?
maybe I should also mention that I'm using a selve-compiled version of Irr1.7.1 in release mode...
Posted: Sun Apr 18, 2010 11:15 pm
by Alastriona
Acki wrote:Alastriona wrote:Acki is using WinXP and minGW.
...
And are you using the precompiled version of Irrlicht or did you compile it yourself?
maybe I should also mention that I'm using a selve-compiled version of Irr1.7.1 in release mode...
Self compiled seems to be the way to go here. I'd say try that if you haven't already bonsalty.
Posted: Mon Apr 19, 2010 12:26 am
by Acki
Alastriona wrote:Acki wrote:Alastriona wrote:Acki is using WinXP and minGW.
...
And are you using the precompiled version of Irrlicht or did you compile it yourself?
maybe I should also mention that I'm using a selve-compiled version of Irr1.7.1 in release mode...
Self compiled seems to be the way to go here. I'd say try that if you haven't already bonsalty.
well, I just tested the pre-compiled gcc version from the sdk and it works, too !!!
so it seems not to be a problem with the re/pre compiled Irrlicht dll, at least not for the MinGW/GCC version...
also tested with OpenGL and DX9...
Posted: Mon Apr 19, 2010 7:34 am
by hybrid
Well, seeing the Nullpointer in the error obviously tells that either the device pointer is bogus, or the memory read file couldn't be created (which only happens very seldomly). So better debug your code and see what is not working, bonsalty. Also, since all others got their code working, it is also obviously *NOT* a problem of using the char array. You just need to tell Irrlicht that the values are only 8bit ints, which was done in the code shown.
Posted: Mon Apr 19, 2010 8:25 am
by Alastriona
hybrid wrote:Well, seeing the Nullpointer in the error obviously tells that either the device pointer is bogus
If something is corrupting his memory then the pointer may very well have been invalidated. But it can't hurt to check if your device is indeed set.
or the memory read file couldn't be created (which only happens very seldomly).
I'm guessing the code will just read whatever is at the memory location that you give it, even if its bogus.
So better debug your code and see what is not working, bonsalty. Also, since all others got their code working, it is also obviously *NOT* a problem of using the char array. You just need to tell Irrlicht that the values are only 8bit ints, which was done in the code shown.
The code above didn't compile for me untill I compiled irrlicht myself. I strong suggest giving this a go. And yeah, you should match the size of the data type used in your array. Also make sure the signedness flag matches the signedness of your data type.
At the moment I'm using unsigned char. So my function looks like:
Code: Select all
terrain->loadHeightMapRAW(file,8,false);
Also theres a special flag for when you are using floats. Its a bool called floatVals, which I think is the 4th arguement.
Posted: Mon Apr 19, 2010 9:47 am
by bonsalty
Ok, I got it work. The terrain appears. But after the second
terrain->loadHeightMapRAW(file,8);
the file gets corrupted?
terrain->loadHeightMapRAW(file,8);
Generated terrain data (129x129) in 0.0000 seconds
terrain->loadHeightMapRAW(file,8);
Error reading heightmap RAW file.
Posted: Mon Apr 19, 2010 11:01 am
by hybrid
Maybe you have to rewind your file before starting it a second time?
Posted: Mon Apr 19, 2010 11:27 am
by bonsalty
LOL. Thanks
