IAnimatedMesh *meshh = smgr->getMesh("shipp.3ds");
ISceneNode* node1 = smgr->addAnimatedMeshSceneNode( meshh ); // playership
//...
ISceneNode * ship[10];
for (int i=0; i<10; i++) {
ship[i]= smgr->addAnimatedMeshSceneNode( meshh );
ship[i]->setMaterialTexture( 0, driver->getTexture("texture.jpg") );
ship[i]->setPosition(vector3df(30*i,0,0)); // just to separate the meshes
}
while (device->run()) {
//...
}
// delete [] ship; <<-- should i delete array of pointers??
I've read about Irrlicht's mesh cache, etc. so i just tried to do this in "rough" way... i dunno how this is supposed to look
also memory usage doesn't seem to change so it seems to work but during several compile-runs memory usage with 10 meshes was lower than without them (LOL)
B@z wrote:well if you dont render anything, it would be high fps
the code is good, there isnt anything you can do wrong with it xD
and you dont have to delete, AFAIK irrlicht cleans automatic when closed
thanks for reply
the problem is, Irrlicht demo for example, has 700.000 triangles (i think) and runs smoothly, while I have only 40.000 triangles and there's such a huge drop of performance. i tried to use octree for the meshes - it helped a little bit, but still when i have all the meshes on screen i have ~150 FPS
As you might know, only 60-75 frames can be seen on the screen, all others are just wasting your gfx card. So don't care for the framerate unless it drops under this threshold. Moreover, the FPS drops faster the higher it is.
Oh, and the demo also has just a few k faces, the counter in the demo shows polys per second. You should probably read about hardware buffers/VBOs. Should help much more than octrees.
And no, never delete plain old C arrays
hybrid wrote:As you might know, only 60-75 frames can be seen on the screen, all others are just wasting your gfx card. So don't care for the framerate unless it drops under this threshold.
yes, i know that. it just bothered me that if such simple scene results in such huge drop in performance how would it be like when i make more complex scenes
Well that is simple.
If you render something with 500FPS one frame takes 2ms to render.
Now if a frame takes 3ms to render the FPS will instantly drop to 333.
You really can't compare framerates at this high level. All you have to care about is that the framerate should not drop below 30 in the worst case and should stay somewhere between 60 and 70 in best case.
Even if you get higher framerates you should at least provide an option for cutting the FPS to a certain amount (vsync for example) because a drop from 150 to 100 FPS can cause the feeling that the game is stottering although it has high enough frame rates.
The important thing with FPS is that they should be as constant as possible, not as high as possible.
If you find a system where the FPS is constant at 30 +/- a few you now what your minimum system requirements are
Software documentation is like sex. If it's good you want more. If it's bad it's better than nothing.