Irrlicht Performance

r2d2 · Post by **r2d2** » Thu May 22, 2008 12:14 am

Hi there,
haven't used Irrlicht for quite a while, but had a look at it every now and then, it's becoming better and better

The thing that interests me now is the performance, the features i need which aren't implemented yet would be a piece of a cake to implement, so the only thing i need to know is whether Irrlicht is fast enough or not. I know that there were some API changes and a slight rework of the internal design, did it bring any significant performance increases?
greetz
R2

hybrid · Post by **hybrid** » Thu May 22, 2008 7:37 am

Yes, because the SVN trunk version now supports VBOs, i.e. hardware mesh buffers. This reduces the amount of information uploaded to the GPU each frame significantly, and can boost the performance between 2-10 times. Other things include enhanced memory handling for textures (dx only, yet) and some important improvements to reduced render state changes under OpenGL. So I guess that you should definitely be able to get much better performance with Irrlicht 1.5 compared to older versions. I haven't done tests, yet, though.

r2d2 · Post by **r2d2** » Thu May 22, 2008 1:19 pm

Sounds quite interesting

Do you know any details about how VBOs are used in Irrlicht or has it already been documented somewhere?
Does Irrlicht do back to front rendering by itself or do i have to take care about that?

MasterGod · Post by **MasterGod** » Thu May 22, 2008 1:29 pm

About VBOs IIRC there was some thread not long ago that hybrid explained how to use'em so I believe you'll be able to find it with a little search.

r2d2 · Post by **r2d2** » Thu May 22, 2008 2:25 pm

How to use them can be found here, a little bit about the internal workings here but what really interests me, these threads are a few months old, but what interests me is about how is it working now? What is the Engine internally doing? I haven't had a look at the Irrlicht Source for quite some time, so i would first have to get into it again, but that would take some time and wouldn't be necessary if everything has already been documented yet. In OpenGL there are for example a few different types of VBOs, which one is used in Irrlicht?
Are pixelbuffers implemented in Irrlicht?

hybrid · Post by **hybrid** » Thu May 22, 2008 3:35 pm

No pixelbuffers. The buffers are created on the first meshbuffer drawing (if requested) and is used instead of the mesh upload for all of the next draw calls. If the mesh changed in between (the setDirty flag is set) the buffer is updated. A hw buffer is deleted from GPU memory once it hasn't been used for some predefined time (IIRC its 1000 frames ATM). The other methods should naturally map to OpenGL methods.
Irrlicht does back to front rendering only for transparent mesh buffers, but wouldn't make sense otherwise.

r2d2 · Post by **r2d2** » Thu May 22, 2008 4:27 pm

AFAIK some shadereffects need back to front drawing or at least they look much better if done that way.
Any plans on implementing pixelbuffers yet?

JP · Post by JP » Thu May 22, 2008 5:08 pm

I imagine shader effects would only need rendering back to front if they did transparency blending, otherwise there's probably no need...

I think they're drawn last, just before all the transparency stuff. Or they're drawn after the transparency stuff, not sure, but i don't think they're ordered. You can check the code in CSceneManager yourself.

BlindSide · Post by **BlindSide** » Sat May 24, 2008 3:58 am

r2d2 wrote:AFAIK some shadereffects need back to front drawing or at least they look much better if done that way.
Any plans on implementing pixelbuffers yet?

Just use a transparent base material and they will be rendered back to front along with all the other transparent stuff.

Incase you were talking about front face culling, then that was also recently implemented in the SVN.

By pixelbuffers do you mean R2VB? I'm sure that sort of thing wont be on the developers list for another 100 years, but if you want to submit a patch feel free to do so.

Cheers

r2d2 · Post by **r2d2** » Sat May 24, 2008 9:23 am

Pixelbuffers are more or less the same as Vertexbuffers, the only difference is that they are normally used to store pixeldata, e.g. textures, in GPU RAM. If PBs aren't implemented are Frambufferobjects implemented? They provide windowing system independent drawing contexts implementing render to texture with the help of FBOs is far the best and especially the fastest way. You can also use FBOs to render offscreen and use the results for special shader effects.

hybrid · Post by **hybrid** » Sat May 24, 2008 9:35 am

Oh, you meant simple pbuffers, that was skipped in favor of FBOs

They are already part of Irrlicht 1.3 IIRC.
I was thinking about pixel buffer objects, which are not that heavily used as of now, but might be integrated into Irrlicht somewhat later on.

r2d2 · Post by **r2d2** » Sat May 24, 2008 10:09 am

No i really was talking about PBOs sorry for that, but they are really hard to distinguish between, at least sometimes

but FBOs should also suit my needs perfectly