Cafu VBOs support proposal.

[ronsaldo]

Hello,
I have been messing a bit with Cafu source code and I have noticed that it only uses immediate mode for geometry drawing, which is deprecated and even removed in more recent versions of OpenGL.
I tried to implement it in Cafu with a varying success. Due to the way that render meshes are currently implemented I had to do several changes to add more flexibility and try to take more advantage of the performance of vertex buffer objects.
Because I didn't asked the development (and there wasn't any branch of development trying to do the same), I decided to leave my work in an incomplete state and leave it just as a small proof of concept, which is in the attached patch.
Only the RendererARB use this new rendering method, RendererOpenGL and RendererNull at least build without any problem. I haven't made any change to the others renderer because I'm using Ubuntu 10.4 AMD64 and they are excluded from the build process.
The reason of why it's complicated to add VBO support is that it's a lot more expensive to draw a mesh with only 1 polygon(FaceNodeT) than one with thousands of them. The added class FaceBatchesNodeT tries to compensate it.

[ronsaldo]

Vertex Buffer Object implementation proposal.

[Carsten]

Dear Ronsaldo,

thank you very much for your patch!

I've not yet fully dug into and read it in detail, but want to do so asap, i.e. over the next couple of days.

You're right that the current MatSys::RendererI API is not particularly suitable for VBO support. This is mostly because the Renderer implementation only knows about a mesh when MatSys::RendererI::RenderMesh(const MatSys::MeshT& Mesh) is called (the mesh is then simply rendered with immediate-mode calls).

Another problem/aspect in this regard is that currently, it is up to the user code to make all the appropriate calls to render a scene, i.e.: render ambient pass, then for each light source render the stencil shadows and the dynamic lighting pass.

Therefore, my gross plan regarding this was/is to change the MatSys::RendererI API so that the user code registers its meshes with the Renderer, and tells it which of the registered meshes are supposed to appear in the next frame.
Such registered meshes might be static (e.g. for FaceNodeT or BezierPatchNodeT meshes), or dynamically be updated by the user code in each frame, e.g. for animated models. Meshes would also have flags like "is shadow caster" and others.
The Renderer implementation would then be free to render all registered meshes that are supposed to appear in the next frame on its own discretion, managing all the rendering passes internally.

Ideally, VBO support (either as outlined above, or in any other way) might be introduced step-by-step in a non-destructive manner. E.g. it might be possible to add VBO support without initially affecting the existing immediate-mode code. Only the second step would then make the transition of existing code to the VBO-only code.

All this being said, I really ought to look into your patch first, and I'll also have to read the VBO extension specs to really get up-to-date in all related matters.
:-)

[Carsten]

(In [417]) Added operators == and != to class ArrayT<T>, and replaced the comparison function callback for the QuickSort() method with a template parameter,
so that the compiler can possibly inline the comparison function, and optionally "functors" can be used in their place.

References #31.