Question on VBOs

[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

[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 I'll promise to get my win32 development machine (VMWare ) up and running in the next days...

[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

[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.

[PI]

Greatness!

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

Regards,
PI

[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!!

[FlyingIsFun1217]

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

[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.

[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:)

[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

[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

[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).

[MasterGod]

With: 162
Without: 176

ATI Radeon HD 2600 Pro.

[BlindSide]

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.

[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).