Page 1 of 1
IrrLicht run Speeds.
Posted: Tue Jun 05, 2007 3:08 pm
by Zrain
GameDude wrote:Also the Irrlicht is pretty fast compared to most other engines.
taken from introduction thread
I'm actually doing an inquest over the next day or two into Irr's Speed.
the demo programs I modified with some just basic "mess around" features all run on my system at a sub par speed for the system.
however I have like 2 instances of Vis studio 2005 runing in the background along with photo shop.. hehe.
the question I think I have to ask you the smart guys is, overall the speed of Irr is similar to other engines?
I'm still in the proses of writing a good statistics class for the event handler to display and track fps, frame time, and geometry counts.
Posted: Tue Jun 05, 2007 5:32 pm
by Luben
No, since each vertex has to be sent over the bus for every frame.
Posted: Tue Jun 05, 2007 8:22 pm
by BlindSide
Luben wrote:No, since each vertex has to be sent over the bus for every frame.
I am always wondering, in this a hidden advantage in the sense that we can manually deform meshes, make mesh manipulation etc without taking a big hit in speed? (Since it is slow anyway from having to send every frame?)
PS: Irrlicht IS pretty fast because it uses 16 bit indices and 16 bit textures etc by default..
Posted: Tue Jun 05, 2007 8:33 pm
by Spintz
It's a 32 bit world( if not more nowadays ). I know DX10 only supports 32 bit color formats for textures.
And no, even if you're deforming a mesh, you're most likely not deforming it every frame, and if you are, maybe only vertices are being changed, not indices, so it's worth uploading index data to a static index buffer and vertex data to a dynamic vertex buffer.
Posted: Tue Jun 05, 2007 8:34 pm
by Saturn
Irrlicht doesn't use 16bit textures by default anymore. Somebody should change this FAQ entry. ^^
And 16bit indices are used by most other 3d engines too, only with the option to also use 32bit indices, if necessary.
And mesh deforming can be either done in a shader (if it is semi-static) or by setting the proper buffer usage flags when using buffers. The diminutive performance hit that's still there can usually be neglected, because 99.452846% of the objects will be static either way. Not having hardware buffers as an option is not an advantage. Making their use optional is. Ogre requires hardware buffers for instance. They are either used always or not at all, no mixed mode available. But this is still better than not having them at all. Here is room for an advantage in Irrlicht future.
Posted: Tue Jun 05, 2007 11:00 pm
by omaremad
I am currently adding hardware shadow volume extrusion, and looking at the code, a stack of about 5 opengl bits was being pushed and poped and about 10 disables for every shadow being drawn! moreover the drawing was done triangle by triangle even though the shadow volume scene node calculates the indices!.
I think irrlicht was designed more for generalness and OO`ness rather than for performance.
allmost all of the implementations of the stuff in the driver's is very generic and not "tuned", gui drawing still uses gl intermediate mode.
Tbh if you look at ogre's source code its actually allot simpler than irrlicht.
Posted: Wed Jun 06, 2007 12:33 am
by hybrid
The stencil drawing is not done per triangle, but uses the usual indexed drawing as the other routines. And state managements is complex, that's right. But since stencil buffers are slow anyway I don't know why exactly this method is a problem?!
GUI is not performance critical. The amount of GUI is neglectible compared to the mesh data, so once again something not too important to optimize.
And third, API counts for render engines, not the code. The developers of the engine are concerned with its code, the users need a simple API. And due to the simple buffer formats and the intuitive structures Irrlicht's API is simple and clean.
Posted: Wed Jun 06, 2007 1:16 pm
by omaremad
Really? all i see is just an array of vertex positions and a glvertexpointer, no indices being passd (which where calculated and used for the edge parts of the shiloete algo), as for the state mangment i took it out and put it as a method that gets callled twice only, before shadow rendering and then after. And about intermediate mode, if the dx driver isnt using it why should the gl one do?
Posted: Fri Jun 08, 2007 10:02 pm
by neoIxen
Another thing is the core::list speed...
Those list-loops are often used in IrrLicht:
Code: Select all
list<ISceneNode*>::Iterator it = Children.begin();
for (; it != Children.end(); ++it)
{
(*it)->doStupidThings();
}
But if there are many members in the list it's slow...
I do my things with arrays
Code: Select all
ISceneNode** it = Children.pointer(); // Children as core::array
for (u32 i=0; i < Children.size(); i++)
{
it[i]->doStupidThingsFaster();
}
In a scene with 10000 node and a manager which updates them there is a difference of 20-30 fps (~60 with lists; 80-90 with arrays)...
maybe lists are faster with just some members, but I need lots of nodes in my current projects
