Hello everyone,
rendering 30 simple Quake2 medic-kit models (summary of 800 faces) yields in a slow 100fps. I think its the result of the drawIndexedTriangleList implementation used.
Will it be possible in future versions to use Hardware vertexbuffers or did I miss something in the engine, that allows that already?
Thanks for your help,
Phil
Poor performance
i get sorta slow FPS too...
but i just figured i had a whole lot of junk loaded was all...
an MD3, a BIG quake3 level, and an ms3d model or weapon models...
all told about 3800-4000 polys at any given time being drawn....
is 60-70 FPS on my celeron2.2 with 768MB DDR and GF4-ti4200 normal?
it is quite possible i am not properly optimizing the compile too, i usually AM building this in debug mode...
an MD3, a BIG quake3 level, and an ms3d model or weapon models...
all told about 3800-4000 polys at any given time being drawn....
is 60-70 FPS on my celeron2.2 with 768MB DDR and GF4-ti4200 normal?
it is quite possible i am not properly optimizing the compile too, i usually AM building this in debug mode...
My irrlicht-based projects have gone underground for now, but if you want, check out my webcomic instead! http://brokenboomerang.net
Re: i get sorta slow FPS too...
This can make a pretty large difference, especially if you don't use the shipped irrlicht.dll, but recompile your own one.buhatkj wrote:it is quite possible i am not properly optimizing the compile too, i usually AM building this in debug mode...
On a related note, I found out that the VC++ .NET Standard Edition I purchased gets shipped with a crippled compiler which does not allow for optimization...
So I'm looking at Intels C++ Compiler now.well im sorta stuck there...
wlp, im sorta stuck then, cuz i use md3's in my game, and for those i need to recompile irrlicht myself, though i still do get half-decent performance, i think what i need to do is just cut down my poly count, maybe also i can try and see if i can recompile my irrlicht and make sure its properly optimized.
i wonder, what options does niko set for best performance when he compile it for the SDK??
~Ted
i wonder, what options does niko set for best performance when he compile it for the SDK??
~Ted
My irrlicht-based projects have gone underground for now, but if you want, check out my webcomic instead! http://brokenboomerang.net
-
SuryIIID_
Poor performance !
Unfortunately i recently found that Irrlicht isnt as "Lightning fast" as it should be...
My suggestion is that using d3dDevice->DrawIndexedPrimitiveUP with primitive type flag set to D3DPT_TRIANGLELIST is not the best way to render every visual in the scene as Irrlicht does.
In most of the cases D3DPT_TRIANGLESTRIP's are faster than LIST's and FAN's and btw as far as i know DrawIndexedPrimitiveUP is used only if applications are unable to store their vertex data in vertex buffers wich are much faster than calling user memory pointers to vertex data as DrawIndexedPrimitiveUP and DrawPrimitiveUP does.
IMO there is so much to optimize in Irrlicht..and i think that currently it runs at half of the speed it can if it's optimized.
Here are some performance boost tips (D3D only) :
1.Clear only when you must.
2.Minimize state changes and group the remaining state changes.
3.Use smaller textures, if you can do so.
4.Draw objects in your scene from front to back.
5.Use triangle strips instead of lists and fans. For optimal vertex cache performance, arrange strips to reuse triangle vertices sooner, rather than later.
6.Gracefully degrade special effects that require a disproportionate share of system resources.
7.Constantly test your application's performance.
8.Minimize vertex buffer switches.
9.Use static vertex buffers where possible.
10.Use one large static vertex buffer per FVF for static objects, rather than one per object.
11.If your application needs random access into the vertex buffer, choose a vertex format size that is a multiple of 32 bits. Otherwise, select the smallest appropriate format.
12.Draw using indexed primitives. This may allow for more efficient vertex caching within hardware.
13.If the depth buffer format contains a stencil channel, always clear the depth and stencil channels at the same time.
14.Use 16 bit modes if you can do so...
There are even more like culling techiques,batching primitives ,lighting tips,
using Direct3DX mesh objects calling their Optimize methods using their attribute ID,buffer and table , Z-Buffer performance tips and etc.
Also the culling part of the engine is extremely important...i noticed that this terrain demo wich performs at 13 FPS on my GeForce4 is not culled at all.. no matter wich direction my camera is looking at and how far it's from the terrain mesh i simply get 13 FPS
there are several culling techniques i know like vector based,frustum culling with clip planes and projection/bounding box culling
The first thing in TODO list should be implementing vertex buffers
for speed sake...
And finally i think there is so much to optimize and i hope that the internal data types like SColor,matrix4,vector3df etc and the mix DX/OGL design will not be a problem to optimize it...
just my 0.2 cents...
My suggestion is that using d3dDevice->DrawIndexedPrimitiveUP with primitive type flag set to D3DPT_TRIANGLELIST is not the best way to render every visual in the scene as Irrlicht does.
In most of the cases D3DPT_TRIANGLESTRIP's are faster than LIST's and FAN's and btw as far as i know DrawIndexedPrimitiveUP is used only if applications are unable to store their vertex data in vertex buffers wich are much faster than calling user memory pointers to vertex data as DrawIndexedPrimitiveUP and DrawPrimitiveUP does.
IMO there is so much to optimize in Irrlicht..and i think that currently it runs at half of the speed it can if it's optimized.
Here are some performance boost tips (D3D only) :
1.Clear only when you must.
2.Minimize state changes and group the remaining state changes.
3.Use smaller textures, if you can do so.
4.Draw objects in your scene from front to back.
5.Use triangle strips instead of lists and fans. For optimal vertex cache performance, arrange strips to reuse triangle vertices sooner, rather than later.
6.Gracefully degrade special effects that require a disproportionate share of system resources.
7.Constantly test your application's performance.
8.Minimize vertex buffer switches.
9.Use static vertex buffers where possible.
10.Use one large static vertex buffer per FVF for static objects, rather than one per object.
11.If your application needs random access into the vertex buffer, choose a vertex format size that is a multiple of 32 bits. Otherwise, select the smallest appropriate format.
12.Draw using indexed primitives. This may allow for more efficient vertex caching within hardware.
13.If the depth buffer format contains a stencil channel, always clear the depth and stencil channels at the same time.
14.Use 16 bit modes if you can do so...
There are even more like culling techiques,batching primitives ,lighting tips,
using Direct3DX mesh objects calling their Optimize methods using their attribute ID,buffer and table , Z-Buffer performance tips and etc.
Also the culling part of the engine is extremely important...i noticed that this terrain demo wich performs at 13 FPS on my GeForce4 is not culled at all.. no matter wich direction my camera is looking at and how far it's from the terrain mesh i simply get 13 FPS
there are several culling techniques i know like vector based,frustum culling with clip planes and projection/bounding box culling
The first thing in TODO list should be implementing vertex buffers
for speed sake...
And finally i think there is so much to optimize and i hope that the internal data types like SColor,matrix4,vector3df etc and the mix DX/OGL design will not be a problem to optimize it...
just my 0.2 cents...
Re: Poor performance !
You are right, there are some thing in Irrlicht, which could be optimized. Vertexbuffers are already planned, and I also saw an extension in the forum, with which it was possible to draw triangle strips.
The reason, why Irrlicht does not use vertex buffers until now is simply, that most applications using Irrlicht do not have any static 3d mesh. Everything is animated and modified, every frame.
The terrain, as you mentioned is far away from being fast: Sure, it is just an alpha version and appeared first in the latest version, 0.4.2. No culling is done with the terrain yet, and not even different level of details are used, as you can read in the changes.txt. Culling with all other scene node works.
But try it out, and compare the engine's performance to other open source engines. Irrlicht is not that slow. It is in fact faster than most of the others.
I don't want to write a comment on all of the points you've listed, but the Engine is doing already lots of things for optimizing speed: Textures are scaled into an optimal size for rendering, render state changes are minimized, 16bit is used as often as possible.
The reason, why Irrlicht does not use vertex buffers until now is simply, that most applications using Irrlicht do not have any static 3d mesh. Everything is animated and modified, every frame.
The terrain, as you mentioned is far away from being fast: Sure, it is just an alpha version and appeared first in the latest version, 0.4.2. No culling is done with the terrain yet, and not even different level of details are used, as you can read in the changes.txt. Culling with all other scene node works.
But try it out, and compare the engine's performance to other open source engines. Irrlicht is not that slow. It is in fact faster than most of the others.
I don't want to write a comment on all of the points you've listed, but the Engine is doing already lots of things for optimizing speed: Textures are scaled into an optimal size for rendering, render state changes are minimized, 16bit is used as often as possible.
I have to agree that the engine seems fairly slow compared to others, such as Ogre and NeoEngine.
I'm not going to knock niko, as anyone who successfully writes a 3d engine/framework deserves my utmost respect. The engine is still in its early stages, and over time it will be optimised and can only improve.
I'm not going to knock niko, as anyone who successfully writes a 3d engine/framework deserves my utmost respect. The engine is still in its early stages, and over time it will be optimised and can only improve.
-
SuryIIID_
Poor performance
@stodge nice to see ya around 
A triangle strip is a series of connected triangles. Because the triangles are connected, the application does not need to repeatedly specify all three vertices for each triangle. For example, you need only seven vertices to define the following triangle strip:
The system uses vertices v1, v2, and v3 to draw the first triangle; v2, v4, and v3 to draw the second triangle; v3, v4, and v5 to draw the third; v4, v6, and v5 to draw the fourth; and so on. Notice that the vertices of the second and fourth triangles are out of order; this is required to make sure that all the triangles are drawn in a clockwise orientation.
Most objects in 3-D scenes are composed of triangle strips. This is because triangle strips can be used to specify complex objects in a way that makes efficient use of memory and processing time.
now let's take a look at triangle lists (currently irrlicht uses them to render objects in DX mode)
A triangle list is a list of isolated triangles. They might or might not be near each other. A triangle list must have at least three vertices and the total number of vertices must be divisible by three.
Use triangle lists to create an object that is composed of disjoint pieces. For instance, one way to create a force-field wall in a 3-D game is to specify a large list of small, unconnected triangles. Then apply a material and texture that appears to emit light to the triangle list. Each triangle in the wall appears to glow. The scene behind the wall becomes partially visible through the gaps between the triangles, as a player might expect when looking at a force field.
Finally i think that having a triangle strip rendering system inside Irrlicht wich alows to decrease the number of vertices to be processed per trangle is very important especially for big flat meshes like terrains.
Btw this information is directly from Microsoft so it could be wrong
Yes VBuffers are quite cool but the most important thing IMO is implementing triangle strips rendering inside the engine because :You are right, there are some thing in Irrlicht, which could be optimized. Vertexbuffers are already planned, and I also saw an extension in the forum, with which it was possible to draw triangle strips
A triangle strip is a series of connected triangles. Because the triangles are connected, the application does not need to repeatedly specify all three vertices for each triangle. For example, you need only seven vertices to define the following triangle strip:
The system uses vertices v1, v2, and v3 to draw the first triangle; v2, v4, and v3 to draw the second triangle; v3, v4, and v5 to draw the third; v4, v6, and v5 to draw the fourth; and so on. Notice that the vertices of the second and fourth triangles are out of order; this is required to make sure that all the triangles are drawn in a clockwise orientation.
Most objects in 3-D scenes are composed of triangle strips. This is because triangle strips can be used to specify complex objects in a way that makes efficient use of memory and processing time.
Code: Select all
d3dDevice->DrawPrimitive( D3DPT_TRIANGLESTRIP, 0, 4);A triangle list is a list of isolated triangles. They might or might not be near each other. A triangle list must have at least three vertices and the total number of vertices must be divisible by three.
Use triangle lists to create an object that is composed of disjoint pieces. For instance, one way to create a force-field wall in a 3-D game is to specify a large list of small, unconnected triangles. Then apply a material and texture that appears to emit light to the triangle list. Each triangle in the wall appears to glow. The scene behind the wall becomes partially visible through the gaps between the triangles, as a player might expect when looking at a force field.
Code: Select all
[code]d3dDevice->DrawPrimitive( D3DPT_TRIANGLELIST, 0, 2 );Btw this information is directly from Microsoft so it could be wrong