Page 1 of 2

Question on VBOs

Posted: Thu Feb 28, 2008 11:50 am
by PI
Hello guys,

I've read somewhere that Irrlicht 1.5 will have both opengl and directx VBOs, and I'm unsure if it'll be useable with my game levels, because it's a custom scene node, which has many meshbuffers, dynamically hidden/shown. So if it's not a mesh scene node, will VBOs work for me? Or, the VBO support is being stronger related to meshbuffers? BTW, why is it so difficult to implement dx VBOs? I'm asking because I've read the opengl part is ready to use.

Thanks for sharing your thoughts,
Cheers,
PI

Posted: Thu Feb 28, 2008 12:03 pm
by hybrid
VBOs work on meshbuffers, so unless you directly use drawVertexPrimitive() to render your mesh it should work.
The DX stuff is not really more difficult than the OpenGL implementation. Now that much organisational stuff is done it should be even simpler. But right now the Windows support by the dev team is currently poor :oops: I'll promise to get my win32 development machine (VMWare :P ) up and running in the next days...

re:

Posted: Thu Feb 28, 2008 12:13 pm
by PI
Wow Hybrid it was a very rapid answer :) Thanks!
Actually, I'm using the drawMeshBuffer call. So, I guess, then it'll work.
Another question if you don't mind:
Will there be any difference between the use of opengl and dx VBOs?

Cheers,
PI

Posted: Thu Feb 28, 2008 4:49 pm
by hybrid
No differences. Since it's a feature of the Meshbuffer interface you will just have to define the type of VBO used, the rest is automatically done.

re:

Posted: Thu Feb 28, 2008 7:58 pm
by PI
Greatness! :D

Thanks for your answers, Hybrid! I'm looking forward to see the speed-up on Irrlicht applications!

Regards,
PI

Posted: Sat Apr 12, 2008 12:13 am
by nutterx
Personally i modified irrlicht along time ago (and when i say along time ago i mean long before version 1.0) and created my own rendering methods that support hardware vertex and index buffers,

works like so:

driver->setVertexBuffer(IVertexBuffer*);
driver->setIndexBuffer(IIndexBuffer*);
driver->drawIndxBuffer(blah,blah);

works great and obviously gives a huge increase in frame rate for anything it is used with.
I can't believe how long it has taken irrlicht to get hardware buffer support!!

Posted: Sat Apr 12, 2008 2:52 am
by FlyingIsFun1217
nutterx wrote: I can't believe how long it has taken irrlicht to get hardware buffer support!!
You and me both! It's the one thing that it doesn't have over... dare I say it... OGRE.

FlyingIsFun1217

Posted: Sat Apr 12, 2008 1:35 pm
by BlindSide
I submitted a patch to the SVN tracker that handles VBOs for DX with the same interface as OpenGL. Feel free to download and use it.

Posted: Sat Apr 12, 2008 3:42 pm
by Nadro
It's very good news:) Thanks BlindSide! but in test I have some problems:

In 02.Quake3Map Example from Irrlicht SDK I have result:
OpenGL with Mesh HardwareBuffer Flag EHM_NEVER: ~375 FPS
OpenGL with Mesh HardwareBuffer Flag EHM_STATIC: ~835 FPS
DirectX with Mesh HardwareBuffer Flag EHM_NEVER: ~320FPS
DirectX with Mesh HardwareBuffer Flag EHM_STATIC: ~320FPS

Meybe this is problem with my drivers, but I think than it is other problem. In your test all works good?

With Hardware Buffer support speed up is very good:) With this support Irrlicht is very very fast engine:)

Posted: Sun Apr 13, 2008 4:06 am
by BlindSide
Thats very strange, with my tests I get 2X speed increase in framerate usually.

Can you post a short test case application with source code so I can run it on my computer and test?

Thanks

PS: I patched the latest SVN, so make sure you are using that too ;)

Posted: Sun Apr 13, 2008 5:01 am
by BlindSide
Ok Nadro, for some reason I get around 250 fps for OpenGL and DirectX whether its EHM_STATIC or EHM_NEVER. I think that maybe OctTreeSceneNode is not so good for hardware buffering because it has to split up the mesh into seperate pieces anyway ;). (This node should be updated so that it sets this flag automatically for its meshes.)

Anyway, try this demo and tell me if you get a framerate increase with hardware buffering (I get 20 to 40fps):

http://irrlichtirc.g0dsoft.com/BlindSid ... errain.zip

Posted: Sun Apr 13, 2008 6:49 am
by Halifax
Well not that I'm part of this conversation. I am getting a 7 FPS increase from 28 to 35 FPS. (ATI Raedon 200M Xpress).

Posted: Sun Apr 13, 2008 7:04 am
by MasterGod
With: 162
Without: 176

ATI Radeon HD 2600 Pro.

Posted: Sun Apr 13, 2008 10:05 am
by BlindSide
MasterGod wrote:With: 162
Without: 176
Whoa :? There is something definately strange about those new radeons (Nadro has one of those too IIRC.)

Maybe it really is something specific to those cards considering Halifaxes seems to work.

Posted: Sun Apr 13, 2008 10:39 am
by sio2
OK, good stuff but it needs a tweak - we're probably not getting the most out of DX9 vertex buffers yet.

Is this in SVN? I synced to SVN 1315 but couldn't see the patch code. Anyway, I applied the patch and tested using the 02.Quake3Map sample.

Firstly, if you run through Debug DX it spits out warnings...
[2928] Direct3D9: (WARN) :Indexbuffer created with POOL_DEFAULT but WRITEONLY not set. Performance penalty could be severe.
[2928] Direct3D9: (WARN) :Vertexbuffer created with POOL_DEFAULT but WRITEONLY not set. Performance penalty could be severe.
...this is because the D3DUSAGE_WRITEONLY flag hasn't been specified. This is what I used
flags = D3DUSAGE_WRITEONLY;
if(HWBuffer->Mapped != scene::EHM_STATIC)
flags = D3DUSAGE_DYNAMIC;
in
bool CD3D9Driver::updateVertexHardwareBuffer(SHWBufferLink_d3d9 *HWBuffer)
The same needs to be applied to CD3D9Driver::updateIndexHardwareBuffer.

Also, resetting flags to zero may be a good idea before locking:
flags = 0;
if(HWBuffer->Mapped != scene::EHM_STATIC)
flags = D3DLOCK_DISCARD;
Using a straight mesh instead of an octree, the WRITEONLY flag jumped my fps from 2080 to 2700; with hardware buffers (VB - Vertex Buffers) I get around 1770 fps. With an octree I get 280fps without VB (as opposed to 1770fps for a straight mesh with VB).