Scalability

[Robomaniac]

For my example, i just took the collision example, and modified it so instead of creating 3 fairies, it did

Code: Select all

if (faerie)
	{
	for (int i=0; i < 501; i++)
	{	
		node[i] = smgr->addAnimatedMeshSceneNode(faerie);
		node[i]->setPosition(core::vector3df(-70,0,-90));
		node[i]->setMD2Animation(scene::EMAT_RUN);
		node[i]->getMaterial(0) = material;

		node[i] = smgr->addAnimatedMeshSceneNode(faerie);
		node[i]->setPosition(core::vector3df(-70,0,-30));
		node[i]->setMD2Animation(scene::EMAT_SALUTE);
		node[i]->getMaterial(0) = material;

		//node[i] = smgr->addAnimatedMeshSceneNode(faerie);
		//node[i]->setPosition(core::vector3df(-70,0,-60));
		//node[i]->setMD2Animation(scene::EMAT_JUMP);
		//node[i]->getMaterial(0) = material;
	}
	}

that code for example, would create 1500 fairies, and i just changed the value until it became too slow

[Marc]

I profiled my program and opened a new thread on it here

http://irrlicht.sourceforge.net/phpBB2/ ... php?t=1556

since I think this is more likely "Open Discussion" than "Advanced Help" about the speed of Irrlicht.

But your loop is interesting. My first approachs was the same, but I displaced each faerie a little bit so that I can them. Perhaps otherwise, Irrlicht is clever enough to clip some of them? I don't know. But I got nearly the same results as now, if I disable collision responding. Try something like this

Code: Select all

for (int iy=0; iy < 20; iy++) 
   for (int ix=0; ix < 20; ix++) 
   {    
      node[i] = smgr->addAnimatedMeshSceneNode(faerie); 
      node[i]->setPosition(core::vector3df(-70+ix*10,0,-90+iy*10)); 
      node[i]->setMD2Animation(scene::EMAT_RUN); 
      node[i]->getMaterial(0) = material; 
   }

This results in a square of faeries. That's pretty slow on my machine too.

[Wolf Dreamer]

I use the most recent version of Visual C++ .net, and have a 1900mhz computer.

I get FPS 9 when making 300 fairies.

FPS 46 when there are only 30 of them.

Perhaps because Microsoft's compiler isn't optimized?

I'm going to try it with dev C now.

[Tels]

100 fairies, ~40000 triangles, 55 fps
200 fairies, 135125 triangles, 22 fps
300 fairies, 203342 triangles, 15 fps
400 fairies, 269295 triangles, 11 fps
600 fairies, 396725 triangles, 7 fps
1000 fairies, 662998 triangles, 6 fps
2000 fairies, 1316633 triangles, 2 fps

I think you guys are overestimating the power of your CPU :o)

First, the results above indicate that the collision detection is probably not the bottle neck.

If you double the number of objects, each object needs to do twice as many checks (against a collision of every other object) and we have twice as many objects. There: double the objects, and four times the number of checks have to be made.

The above stats are linear, meaning double the number of objects, and it takes only (:) twice as long. thats actually quite good (or the objects only collide with the level, but not with themselves, or some clever optimization is going on).

Another point is: Have anybody of you played the demo of painkiller? That game slows down to a crawl if there are more than 10-20 enemies on the screen. I I would say that their engine (both grafically as well as the physics) is optimized as hell. If you manage to move arund 400 fairies without crashing the system, I would say this is quite an achievement :)

Best wishes,

Tels

[Robomaniac]

kinda offtopic, but the pk demo was sweet, but did slow down to a crawl even on my system, of course, i just had to turn it down to 800 x 600 instead of 1024 x 768 and it ran fine

[Marc]

I only have VC6. The compiler from 7 optimizes a bit better, but a factor of 10 ist far away from realistic.

46 fps is nearly twice as fast as my result with 30 faeries. But still it isn't a desireable result. If you have an Intel, perhaps the collisions can be calculated faster what may explain the difference.

300 gives me 2 fps if I look in the direction of the fairies and 4 if I look in the opposite direction...

[Tels]

You also need to keep in mind that Irrlicht doesn't have a LOD system yet, e.g. faries near you have the same amount of polygons than the ones more far away. Any many triangles can kill the performance rather quick.

In any event, I still remember me piling up 500 barrels of gunpower in the Thief Editor and then blowing them up in the game - after some initial explosions it managed a frame every 10-60 seconds or so :-)

Best wishes,

Tels

[Marc]

No that's not the point. Todays graphiccards can handle 20k-30k triangles without such a low framerate. The triangle counts of my test are low enough that a LOD system won't receive anything.

[Tels]

"No that's not the point. Todays graphiccards can handle 20k-30k triangles without such a low framerate. The triangle counts of my test are low enough that a LOD system won't receive anything."

But doesn't Irrlicht need some more time if you have more triangles in the queue (even when you don't do collison detection) as well as does Irrlicht spent more time handling 300 (instead of 30) objects?

I think we are agreeing on the basic points (e.g. Irrlicht could be optimized), I just wanted to point out that you shouldn't expect miracles :)

Cheers,

Tels

[Marc]

I wasn't talking about 300 objects. If triangle count rises, there are other limitations for sure. But 30k triangles at a desireable framerate is no miracle.

pleasent dreams,

Marc

[vermeer]

sorry this dumb artist intrussion, but in other engines the number of surfaces (objects) hits dramatically the fps. A 30k tris in certain engine that I remember, done with a single terrain mesh, did went totally fluid, and when done so with that count but with some few meshes, the fps did fail down incredibly. I was told often this is logical in other engines.

Don't ask me why...

[Masdus]

If all that was happening is placing triangles on the screen 30k tris would be resonable, but frame rate is also affected by any other code, like collison detection. FPS in not only a function of the grahics card but also the CPU work needed fo each frame. As stated before every increase in a object requires more CPU time per frame for collision dectection. The frame will not be drawn until this is complete so the graphics card could have already finished its work and be waiting for the CPU to finish (although in this case i'm pretty sure the collisions need to be completed so the graphics card draws the objects in the one place). Traditionally if you want to test the triangle count bottle neck you would use either a single high detail model or a terrain model.

[Luke923]

Speaking of bottlenecks, here's a snippet from game:

Code: Select all

	io::IFileSystem*	FS = IDevice->getFileSystem();
	FS->changeWorkingDirectoryTo("C:\\progs\\espionage\\media\\meshes\\");
	io::IFileList* FLCL = FS->createFileList();
	
	for(u32 h = 0; h < FLCL->getFileCount(); h++)
		AddMesh((c8*)FLCL->getFileName(h));

	FS->changeWorkingDirectoryTo("c:\\progs\\espionage\\media\\MeshTextures\\");
	FLCL = FS->createFileList();

	for(h = 0; h < FLCL->getFileCount(); h++)
		AddTexture((c8*)FLCL->getFileName(h));

	LoadLevelFromFile("c:\\progs\\espionage\\l001.yuf");

when it was all said and done, I had something around 150 .3ds files ranging from 1KB to 100KB that it loaded in realtime. Also, I had about 8 textures it placed on each of those meshes in real time. The program ate 110MB of memory, but killed the CPU/GPU as I was getting probably 2FPS.

You see, I learned something that day: Just because you can load something into memory doesn't mean you should.