Irrlicht seems to be slow

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
Marc
Posts: 25
Joined: Wed Feb 11, 2004 1:03 pm
Contact:

Irrlicht seems to be slow

Post by Marc »

I profiled my program I already mentioned here

http://irrlicht.sourceforge.net/phpBB2/ ... =8399#8399

:

http://www.rhrk.uni-kl.de/~rochel/files ... cstest.zip

It loads the techdemo map and a number of fairies u can specify at startup (src included, If you'ld like to have a look)


CollidesSlide is where I call getCollisionResultPosition:

Code: Select all

void Visual::CollideSlide(float *p, float *v, bool *falling, float *pnew)
{
	core::triangle3df tri;
	core::vector3df res=colmgr->getCollisionResultPosition(
		selector,
		core::vector3df(p[0],p[2]+15,p[1]),
		core::vector3df(10,40,10),
		core::vector3df(v[0],v[2],v[1]),
		tri,
		*falling,
		0.0005f,
		core::vector3df(0,-9,0)
	);
	pnew[0]=res.X;
	pnew[2]=res.Y-15;
	pnew[1]=res.Z;
}
Render initiates the rendering of 1 frame:

Code: Select all

void Visual::Render()
{
	driver->beginScene(false, true, 0);
	smgr->drawAll();
	driver->endScene();
	int fps = driver->getFPS();

	static int lastFPS;
	if (lastFPS != fps)
	{
		wchar_t tmp[1024];
		swprintf(tmp, 1024, L"Marc's Irrlicht Testgame - (fps:%d) Triangles:%d", 
			fps, driver->getPrimitiveCountDrawn());
		device->setWindowCaption(tmp);
		lastFPS = fps;
	}
}
So these Methods of Visual are only wrappers arounf Irrlicht are not to src of for framerate slowdowns.


First I used 50 fairies, I got 15fps, and here are the timings:

Code: Select all


        Func          Func+Child           Hit
        Time   %         Time      %      Count  Function
---------------------------------------------------------
   24346,182  61,7    24407,416  61,9    25806 Visual::CollideSlide(float *,float *,bool *,float *) (visual.obj)
   12498,282  31,7    12498,444  31,7      506 Visual::Render(void) (visual.obj)
    1120,676   2,8    39396,302  99,9      782 CWinThread::PumpMessage(void) (mfc42d.dll)
     609,633   1,5      609,645   1,5        1 Visual::LoadMap(char *) (visual.obj)
     127,017   0,3      189,732   0,5        1 Visual::Init(void) (visual.obj)
     110,084   0,3      219,180   0,6   129589 AfxAssertValidObject(class CObject const *,char const *,int) (mfc42d.dll)
      85,801   0,2      352,088   0,9   129030 CMap<unsigned int,unsigned int,class ZObject *,class ZObject *>::GetNextAssoc(struct __POSITION * &,unsigned int &,class ZObject * &) (world.obj)
      79,536   0,2    24884,484  63,1      506 World::Iterate(void) (world.obj)
      62,482   0,2       62,704   0,2        1 irr::createDevice(enum irr::video::EDriverType,class irr::core::dimension2d<int> const &,unsigned int,bool,bool,class irr::IEventReceiver *,unsigned short const *) (irrlicht.dll)
      53,179   0,1       53,179   0,1   145014 AfxIsValidAddress(void const *,unsigned int,int) (mfc42d.dll)
      51,621   0,1       84,342   0,2   129589 CMap<unsigned int,unsigned int,class ZObject *,class ZObject *>::AssertValid(void) (world.obj)
      47,952   0,1    39447,236 100,0        1 CDialog::DoModal(void) (mfc42d.dll)
As u can see, Irrlicht spends a lot of time on calculating the sliding.


Without Collisionresponsing, I got 30 fps and these timings:

Code: Select all

        Func          Func+Child           Hit
        Time   %         Time      %      Count  Function
---------------------------------------------------------
   23181,167  87,7    23181,360  87,7      875 Visual::Render(void) (visual.obj)
    1408,637   5,3    26353,222  99,7     1494 CWinThread::PumpMessage(void) (mfc42d.dll)
     555,843   2,1      555,855   2,1        1 Visual::LoadMap(char *) (visual.obj)
     219,320   0,8      422,140   1,6   224053 AfxAssertValidObject(class CObject const *,char const *,int) (mfc42d.dll)
     179,142   0,7      234,328   0,9        1 Visual::Init(void) (visual.obj)
     149,961   0,6      636,152   2,4   223125 CMap<unsigned int,unsigned int,class ZObject *,class ZObject *>::GetNextAssoc(struct __POSITION * &,unsigned int &,class ZObject * &) (world.obj)
     112,316   0,4      839,242   3,2      875 World::Iterate(void) (world.obj)
So without sliding, there is nothing else that slows down the framerate than the rendering itself. Compared to other current 3d engines, this is a pretty slow result I think.

Something has to be done in model-handling I think. We need to be able to have 50 objects moving around in a map, with correct collision detection/sliding without such a slowdown in framerate.

In relation to this, I'ld like to know about the level of optimiziation of collision and rendering functionality. So niko, do u think these functions are optimized very much or do u think it's possible to speed them up?

I don't want to blame u. Irrlicht has a wonderful easy interface and does lots of things I'ld never like to implement myself. But it's too slow right now I think.

Comments appreciated
2D-Splatter-Action => http://www.walkover.de.vu <=
niko
Site Admin
Posts: 1759
Joined: Fri Aug 22, 2003 4:44 am
Location: Vienna, Austria
Contact:

Post by niko »

Hi, there is heavy optimization possible and necessary in axaclty the areas you mentioned. First, Irrlicht currently use Vertex buffers for example. This slows rendering down a lot. And second, the way the occtree is created for the collision detection is not very optimal. It depends very on the way the geometry looks like, but for example the .bsp which comes with the SDK is very bad. To speed it up a lot, this tree could be changed in that way, that it splits triangles, which cover more than one leave. Also, the way and how often collisions are detected could be improved a lot. All this is in my plans, but it has no big priority currently. I first would like to implement the very basic things. And to answer your question: Yep, I think it is possible to fix this by yourself. :)
Marc
Posts: 25
Joined: Wed Feb 11, 2004 1:03 pm
Contact:

Post by Marc »

As far as I understand your src, I think the models are not clipped to the map. I think this would help a lot as a first approach. But therefore the models, or scenenodes in general, have to be sorted into the octree of the map, what seems to be against the current design, or am I wrong?
2D-Splatter-Action => http://www.walkover.de.vu <=
niko
Site Admin
Posts: 1759
Joined: Fri Aug 22, 2003 4:44 am
Location: Vienna, Austria
Contact:

Post by niko »

Currently they are not, right. But I plan to extend some scene nodes (like the octree, or creating a new one, like a psv-thing) to clip and manage their children. So if you place a node as child of a big map, it is able to prevent it to render the child if it knows that it is behind a wall for example.
Marc
Posts: 25
Joined: Wed Feb 11, 2004 1:03 pm
Contact:

Post by Marc »

That would probably be a good idea. This and an Optimization of the collisiondetection would help to make a big step forward in useability.
2D-Splatter-Action => http://www.walkover.de.vu <=
bappy
Posts: 63
Joined: Fri Dec 12, 2003 10:49 am
Location: france
Contact:

Post by bappy »

i think the optimisation must be at last.
in game company, when a game is coding, whe just simply code the game, and 2 month before the release, we optimize it, that s it.
-----------------------------
Sans danger, pas de gloire...
http;//bappy.free.fr
-----------------------------
Marc
Posts: 25
Joined: Wed Feb 11, 2004 1:03 pm
Contact:

Post by Marc »

We are not talking about code optimization, we are talking about analytical optimization.
2D-Splatter-Action => http://www.walkover.de.vu <=
Post Reply