Apricot BGE VBO patch and a fix for hipoly objects. #17523

New Issue

Samuel Anjam · 2008-08-25T14:19:48+02:00

Samuel Anjam commented

2008-08-25 14:19:48 +02:00

%%%This patch is built on apricot branch since it contains newer rasterizer code than the trunk. Thus this patch won't work on trunk.

In addition to the VBOs, I made an important fix for hipoly objects. Previously if an object had more than 65K indices, an new display array would be created for EACH FACE instead of creating a new display array and filling that one up. This makes rendering REALLY slow for faces that exceed the 65000th indice.

The VBOs are detected and used automatically if the hardware supports them.%%%

%%%This patch is built on apricot branch since it contains newer rasterizer code than the trunk. Thus this patch won't work on trunk. In addition to the VBOs, I made an important fix for hipoly objects. Previously if an object had more than 65K indices, an new display array would be created for EACH FACE instead of creating a new display array and filling that one up. This makes rendering REALLY slow for faces that exceed the 65000th indice. The VBOs are detected and used automatically if the hardware supports them.%%%

Samuel Anjam commented

2008-08-25 14:19:48 +02:00

Changed status to: 'Open'

Samuel Anjam commented

2008-08-26 01:58:46 +02:00

%%%Fixed a bug which caused random crashes on windows. The color VBO was being over allocated and malicious data was loaded into the vbo from an array which was expected to be longer.%%%

Brecht Van Lommel commented

2008-08-26 13:57:38 +02:00

%%%OK, some initial comments from reading the patch:

Please add some empty lines in InitVboSlot, it's hard to read like this.
In InitVboSlot, I wouldn't use array->m_vboSlot->m_verts but just float *verts, only makes it more confusing since it is deleted at the end anyway.
Is a separate UpdateMeshSlotData function needed? It could do these things from IndexPrimitives too, I think, though an extra "animated" value would need to be added to RAS_MeshSlot.
For animated objects, the normals must be updated too.
I wouldn't call glVertexPointer(3, GL_FLOAT, 0, 0); and such for cleanup, there's no need, it has to be set to something else anyway, NULL would also be invalid regardless. Or is there a reason?

Most importantly, are you seeing performance improvements compared to display lists, and if so, how much?
%%%

%%%OK, some initial comments from reading the patch: * Please add some empty lines in InitVboSlot, it's hard to read like this. * In InitVboSlot, I wouldn't use array->m_vboSlot->m_verts but just float *verts, only makes it more confusing since it is deleted at the end anyway. * Is a separate UpdateMeshSlotData function needed? It could do these things from IndexPrimitives too, I think, though an extra "animated" value would need to be added to RAS_MeshSlot. * For animated objects, the normals must be updated too. * I wouldn't call glVertexPointer(3, GL_FLOAT, 0, 0); and such for cleanup, there's no need, it has to be set to something else anyway, NULL would also be invalid regardless. Or is there a reason? Most importantly, are you seeing performance improvements compared to display lists, and if so, how much? %%%

Samuel Anjam commented

2008-08-26 14:24:52 +02:00

%%%* I will add the empty lines to InitVboSlot

You have a point there. I changed some of the major code and forgot to make that function smarter.
The animated flag would be very useful, I didn't go around adding that because I don't really have an idea where that should be done (setting it continuously in RenderMeshSlot sounds like a bad idea...), haven't gotten around the code that much yet.
I thought that only the coordinates were updated... Didn't see anything else in BL_MeshDeformer::Apply. Are the normals recalculated somewhere else? Once this has been cleared up, I'll add the normal update.
The clear up is there because once I add the check if memory is available in the GPU to the InitVboSlot function, it is possible that the VBOs don't get fully initialized and in case this happens, it falls back to non vbo mode for the meshes that didn't get their vbos fully initialized. Now when you render something with vbos, obviously you have to bind them first and if by any chance you render something non vbo after that, it might crash if some vbos are bound. Thats why all of them are unbound. This shouldn't make the rendering any slower I think.

Display lists are still the fastest method of rendering and they beat vbos by a little. But the thing with display lists is that they take much more memory than vbos and they are certainly not suitable for the type of scenes that are found in todays games. Display lists are optimal for rendering really big amounts of small objects, but nowadays pretty much everything major is rendered with vbos. This is an industry standard and I think that it would be wise to follow this standard in the BGE too.

Also display lists aren't suitable for animations and transparent objects due to their static nature. VBO data can be reuploaded, thus supporting animation and zsorting.

VBOs compared to non vbo rendering:
VBOs are optimal for high poly scenes. The performance doesn't differ that much with low poly scenes (especially when the GLSL shaders are enabled, lots of pixel calculations compared to vertex calcs). With 150K triangles I get about 52fps in the non vbo mode and 112fps with vbos. One guy said in the testing thread that he got 169fps with 700K+ triangles + my vbo patch and 13fps without my vbo patch.%%%

%%%* I will add the empty lines to InitVboSlot * You have a point there. I changed some of the major code and forgot to make that function smarter. * The animated flag would be very useful, I didn't go around adding that because I don't really have an idea where that should be done (setting it continuously in RenderMeshSlot sounds like a bad idea...), haven't gotten around the code that much yet. * I thought that only the coordinates were updated... Didn't see anything else in BL_MeshDeformer::Apply. Are the normals recalculated somewhere else? Once this has been cleared up, I'll add the normal update. * The clear up is there because once I add the check if memory is available in the GPU to the InitVboSlot function, it is possible that the VBOs don't get fully initialized and in case this happens, it falls back to non vbo mode for the meshes that didn't get their vbos fully initialized. Now when you render something with vbos, obviously you have to bind them first and if by any chance you render something non vbo after that, it might crash if some vbos are bound. Thats why all of them are unbound. This shouldn't make the rendering any slower I think. Display lists are still the fastest method of rendering and they beat vbos by a little. But the thing with display lists is that they take much more memory than vbos and they are certainly not suitable for the type of scenes that are found in todays games. Display lists are optimal for rendering really big amounts of small objects, but nowadays pretty much everything major is rendered with vbos. This is an industry standard and I think that it would be wise to follow this standard in the BGE too. Also display lists aren't suitable for animations and transparent objects due to their static nature. VBO data can be reuploaded, thus supporting animation and zsorting. VBOs compared to non vbo rendering: VBOs are optimal for high poly scenes. The performance doesn't differ that much with low poly scenes (especially when the GLSL shaders are enabled, lots of pixel calculations compared to vertex calcs). With 150K triangles I get about 52fps in the non vbo mode and 112fps with vbos. One guy said in the testing thread that he got 169fps with 700K+ triangles + my vbo patch and 13fps without my vbo patch.%%%

Brecht Van Lommel commented

2008-08-26 20:18:28 +02:00

%%%I can see the advantage for animated and transparent objects yes, avoiding to upload everything again. But I didn't find a performance difference with this patch on an apricot level. Those statistics you give, is that with or without display lists?

I'm guessing that at least in my graphics card's driver, the display list is compiled to pretty much the same thing as a VBO is. If that is the case, I also don't understand display lists would use that much more memory?%%%

%%%I can see the advantage for animated and transparent objects yes, avoiding to upload everything again. But I didn't find a performance difference with this patch on an apricot level. Those statistics you give, is that with or without display lists? I'm guessing that at least in my graphics card's driver, the display list is compiled to pretty much the same thing as a VBO is. If that is the case, I also don't understand display lists would use that much more memory?%%%

Samuel Anjam commented

2008-08-26 20:43:46 +02:00

%%%The apricot levels use the GLSL system extensively so you can't really tell the difference between vbo and non vbo rendering since the pixel calculations cover it up. (shaders are heavy). You start to see the difference when you are trying to render several high poly objects (20K+ faces) and also when you have something like 200K faces visible on the screen at the same time. VBOs are all about processing large amounts of vertex data. The apricot levels are fairly low poly and use shaders extensively, so the optimization doesn't show up that much.

Here is a document about why people should use vbos: http://spec.unipv.it/gwpg/gpc.static/vbo_whitepaper.html%%%

%%%The apricot levels use the GLSL system extensively so you can't really tell the difference between vbo and non vbo rendering since the pixel calculations cover it up. (shaders are heavy). You start to see the difference when you are trying to render several high poly objects (20K+ faces) and also when you have something like 200K faces visible on the screen at the same time. VBOs are all about processing large amounts of vertex data. The apricot levels are fairly low poly and use shaders extensively, so the optimization doesn't show up that much. Here is a document about why people should use vbos: http://spec.unipv.it/gwpg/gpc.static/vbo_whitepaper.html%%%

Samuel Anjam commented

2008-08-26 20:54:34 +02:00

%%%oh, and no, display lists weren't enabled during the tests ;).%%%

Brecht Van Lommel commented

2008-08-26 21:02:13 +02:00

%%%I've tried artificial high poly scenes too, no difference. Even on an animated high poly mesh it didn't matter for me, probably because the armature deform was the bottleneck there anyway. Those 150K triangles you tested, was that with display lists?

I'd just like to know if this patch improves performance, on some graphics cards or even if just a bit :). Still it's useful to add this I think, even if it doesn't give immediate benefits, but I'm just hoping it does, in some way I'm not thinking of.%%%

%%%I've tried artificial high poly scenes too, no difference. Even on an animated high poly mesh it didn't matter for me, probably because the armature deform was the bottleneck there anyway. Those 150K triangles you tested, was that with display lists? I'd just like to know if this patch improves performance, on some graphics cards or even if just a bit :). Still it's useful to add this I think, even if it doesn't give immediate benefits, but I'm just hoping it does, in some way I'm not thinking of.%%%

Samuel Anjam commented

2008-08-26 21:33:14 +02:00

%%%Thats really weird... Which GPU do you have? Are you sure that it supports vbos? (should support if you have GLSL shaders...)

With my computer and on this guys computer the vbos give a nice boost. I got GeForce 7400 Go.

Please try with this scene: http://rapidshare.com/files/140338836/multipoly.blend.html

Also I have made the changes you requested for except the one for the removal of UpdateMeshSlot, still working on that ;).%%%

%%%Thats really weird... Which GPU do you have? Are you sure that it supports vbos? (should support if you have GLSL shaders...) With my computer and on this guys computer the vbos give a nice boost. I got GeForce 7400 Go. Please try with this scene: http://rapidshare.com/files/140338836/multipoly.blend.html Also I have made the changes you requested for except the one for the removal of UpdateMeshSlot, still working on that ;).%%%

Brecht Van Lommel commented

2008-08-27 12:21:07 +02:00

%%%Well, display lists disabled in the new patch compared to display lists enabled without it doesn't improve performance for me. It is exactly the same in fact, 289 fps for both, on a Nvidia 8800. I think the difference would be in the drivers then, some might not be as smart in compiling display lists as others, because I can't think of another reason why this should make a performance difference.

Also, the big performance difference this other person is seeing is likely because of the bug that is fixed in this patch with creating buckets.%%%

%%%Well, display lists disabled in the new patch compared to display lists enabled without it doesn't improve performance for me. It is exactly the same in fact, 289 fps for both, on a Nvidia 8800. I think the difference would be in the drivers then, some might not be as smart in compiling display lists as others, because I can't think of another reason why this should make a performance difference. Also, the big performance difference this other person is seeing is likely because of the bug that is fixed in this patch with creating buckets.%%%

Samuel Anjam commented

2008-08-27 13:24:39 +02:00

%%%Eh, you are not supposed to test it with display lists. VBOs are supposed to outperform vertex arrays but not display lists and it doesn't really make any difference to display lists if you compile them with vbos or without. The VBO patch is not meant to outperform the display lists but to provide an alternative to them which is almost as fast, more dynamic and more elegant, standard rendering method which everyone is using nowadays.

But oh well, I attached a separate patch for the material bucket fix only. Atleast you can apply that ;).%%%

%%%Eh, you are not supposed to test it with display lists. VBOs are supposed to outperform vertex arrays but not display lists and it doesn't really make any difference to display lists if you compile them with vbos or without. The VBO patch is not meant to outperform the display lists but to provide an alternative to them which is almost as fast, more dynamic and more elegant, standard rendering method which everyone is using nowadays. But oh well, I attached a separate patch for the material bucket fix only. Atleast you can apply that ;).%%%

Dalai Felinto commented

2009-05-25 23:39:24 +02:00

%%%Hi Samuel.

I updated your patch (BUGFIX001.patch) to current SVN. Since 2.49 is feature frozen it was commited to the branch bb_dev instead. There lays the BGE code that will make it's way in trunk after 2.49 official release.

Thanks for this work. I want to implement full glsl skinning for deformed meshes and VBO is a very good start.

I couldn't get your test files though. Could you send them again?%%%

%%%Hi Samuel. I updated your patch (BUGFIX001.patch) to current SVN. Since 2.49 is feature frozen it was commited to the branch bb_dev instead. There lays the BGE code that will make it's way in trunk after 2.49 official release. Thanks for this work. I want to implement full glsl skinning for deformed meshes and VBO is a very good start. I couldn't get your test files though. Could you send them again?%%%

Samuel Anjam commented

2009-05-29 14:45:33 +02:00

%%%Hi.

I'm afraid that the test files are long gone. My laptops motherboard burned up and I sent it to warranty repair, they didn't get it repaired and didn't even send the laptop back to me so I couldn't get HD from it. Even if I did, I don't know would I still have those files.

It shouldn't be that difficult to make some simple test files though ;). Just add something with a lot of vertices, about 100K should start to show some significant improvement on pretty much all up to date GPUs or GPUs starting from the GeForce 6xxx generation.%%%

%%%Hi. I'm afraid that the test files are long gone. My laptops motherboard burned up and I sent it to warranty repair, they didn't get it repaired and didn't even send the laptop back to me so I couldn't get HD from it. Even if I did, I don't know would I still have those files. It shouldn't be that difficult to make some simple test files though ;). Just add something with a lot of vertices, about 100K should start to show some significant improvement on pretty much all up to date GPUs or GPUs starting from the GeForce 6xxx generation.%%%

Tom Musgrove commented

2012-03-31 18:57:27 +02:00

%%%Hi, trying to update the status of the patch tracker. Please respond if this patch is still viable/useful and needs review or if it can be closed.%%%

Mitchell Stokes commented

2014-07-01 06:22:51 +02:00

Changed status from 'Open' to: 'Archived'

Mitchell Stokes closed this issue

2014-07-01 06:22:51 +02:00

Mitchell Stokes self-assigned this 2014-07-01 06:22:51 +02:00

Mitchell Stokes commented

2014-07-01 06:22:51 +02:00

We have VBOs in master (based on this patch I believe).

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Apricot BGE VBO patch and a fix for hipoly objects. #17523