SColor for OpenGL and Vertex Buffering

[Raedwulf]

Yes my implementation of vertex buffers is what you've described hybrid. So far it works for static meshes and it works for MD2 Animated meshes.

I've yet to implement it more cleanly for MD2 animated meshes but its 'working' atm.

Been busy, so progress is slow, but its... progressive ....

[ssexton]

Hello:

I was wondering what would be the best way to remove the conversion from ARGB to RGBA in SColor for the OpenGL renderer.
I see irrspintz does it by using a toggle for the colours to suggest which driver is being used.

Anyone thought of a neater way?

Cheers.

I've wondered about this myself every now and then, but frankly, if I wanted to spend time on OpenGL optimization in Irrlicht I'd be looking into display lists waayy before I looked at this - in other apps, I've seen 4x speedup from those. Irrlicht's font implementation is a natural place to start, it shouldn't be too hard to make it agreeable to glCallLists. I've heard rumors that DX10 has display lists now too, so it could also benefit.

On the subject of your SColor, the best I've come up with is:

- Add an #ifdef in IrrCompileConfig.h to control what the "native" ordering of an SColor is. Let this #ifdef control which driver has to do the swapping (DX or OGL). In theory, this approach *will* produce a non-zero gain in the OGL driver, at the expense of the DX driver. In practice, it may not be a measureable gain and so in that sense not worth doing. But, it shouldn't break any code. At least, not any code that wasn't arguably "wrong" to begin with (code that does direct bit manipulation rather than using the setters on SColor will have the problem).

Note I haven't looked at IrrSpintz so no idea if this is what it is doing or not.

[Raedwulf]

I've realised converting the colours prior to creating vertex buffers is sufficient. Then the vertex buffer contain the correct colour encoding for opengl and there is not runtime implication.

I will look into display lists as well... But need to keep up with my Uni work :S.

---

An interesting sidenote: OpenGL vertex buffers in Linux for 02.Quake3Map work at 3900-4000fps while on windows it goes at 2900-3000fps... (directx9 goes about 3300-3500fps)
This is with a Intel E6600 and Geforce 8800GTS 320mb.

---
IrrSpintz assumes that only one device type will ever be created so it decides at runtime which format it should use according to the device created.

[Raedwulf]

I was wondering whether the implementation of some of the scene nodes should use vertex buffering implicitly if the capability is supported and there are no disadvantages to using them (except of course using video memory). For example, the terrain scene node, all the data is already stored in mesh buffers and all you need to do is to enable vertex buffering and thats it... . Should the capability to enable vertex buffering be provided... or should it be implicit?.

On the other hand say the MD2 Animated Mesh, the current irrlicht code interpolates each frame when required. However, in order to have the benefits of vertex buffering, one must pre-calculate all the frames. The additional memory usage is not that great I guess... but I provided a method to enable vertex buffering. Should this be implicit too?

Well, can I hear your words of wisdom hybrid ?

cheers!

[hybrid]

I think there should be the possibility to make this manually (i.e. call a method to use the buffer) and also provide some means to make it automatically. Doing it inside scene nodes (custom or not) would mean that we have a public method. But using enhanced buffer types or something similar would make access easier.

[Raedwulf]

Ok here's a pre-pre-alpha of what i've done so far... basically this is a dump of my source and nothing to be proud of

MeshBuffers, Meshes, DX9 and OGL, MD2 animation and terrain scene node have vertex buffering.

You might like to have a look at the opengl extensions because those are definitely complete.

So I recommend just for starters to maybe include in the current svn
include/EDriverTypes.h
source/irrlicht/COpenGLExtensionHandler.cpp
source/irrlicht/COpenGLExtensionHandler.h

because those are complete.

The DX9, OGL, Null drivers should also be complete but its up to you to decide whether the interface is suitable.

Credits go to Spintz on video driver code because they are mainly based on his.

Btw the code is not latest svn either... its one of the later ones but I can't remember which .

Basically the code is just an outline about what we've discussed so far minus your last post because I've had no time to implement that .

Here's a link:
http://www.jeeastwood.co.uk/irrlicht-vb-06-11-2007.zip (ready 5min after this post)