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..
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.
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.
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.
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
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.
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?
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
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
