Irrlicht Engine

the hardware buffers can be set differently for vertices and indices, yes.

scene::CDynamicMeshBuffer looks interesting (this is in the current SVN). I'll look into it.

That's the 32bit indices meshbuffer. You can use dynamic index buffers with all other meshbuffer types as well. Check setHardwareMappingHint in IMesh/IMeshBuffer. It has parameters to specify which type (vertex/index) should be set to which type (none,static,dynamic).

I've more implementation to do before I look closely at performance, but I think I will need to add functionality in order to get best performance. I basically need an index buffer with DISCARD and NOOVERWRITE locking semantics. [The principle applies equally to vertex buffers, though in my particular case I put my verts in a static buffer.] I'll have a buffer of indices which I will start to fill with the faces for the first material; I'll then issue a meshbuffer draw call (I need to specify start of indices and number of indices or primitive count) and then lock the next section of the index buffer with NOOVERWRITE so the next draw call doesn't block on the previous ones. This style of buffer locking allows the driver to queue up non-blocking draw calls.

Some extension of the existing vertex and index buffers with an extra draw call would probably do the job. I'll report back with some feature suggestions once I've studied it more closely.

Cool. Looking forward to it

Brief update:

Work is coming along OK. Some algorithm changes improved the framerate greatly. There's a lot of culling: initial scene node culling, Q3 VIS culling and leaf culling against the frustum - I can lock the PVS at a camera position to see what's being culled.

Irrlicht doesn't have the exact index buffer usage I need, but then nor does IrrSpintz. I'll come back to this in my next performance optimisation phase - I'm currently still implementing features.

I'll put together an alpha demo in a week or two, hopefully...

Does this culling also help on low-end cpus? The Pandora port might need some FPs improvements, especially for the q3 maps, as these are the most commonly used maps. And of course no reason why we shouldn't add some more states for the hw buffers - any speed gain is appreciated

hybrid wrote:Does this culling also help on low-end cpus? The Pandora port might need some FPs improvements, especially for the q3 maps, as these are the most commonly used maps. And of course no reason why we shouldn't add some more states for the hw buffers - any speed gain is appreciated

I would expect gains across-the-board in any non-trivial Quake3 map. The test level that's used with the 02.Quake3Map example is a nice, self-contained map but is a bit simple compared to many other Q3 levels. There's also the fact that alpha-blended faces for the main world geometry are automatically sorted back-to-front from the bsp tree - and culled down considerably by camera frustum culls and the Q3 VIS. Then there's light management - a list of visible lights can be obtained. And scene nodes can be inserted into the tree and culled using the Q3 VIS. And the content of leaves can be queried - you can tell if the player is underwater, for example. I use CDynamicMeshBuffer so I can support those massive levels that need 32bit indices.

Lots of good stuff.

I'll get a demo out soon...