Raydium 3D Game Engine

Hi there,
Please correct me if I get things wrong, I've not extensively studied the raydium source, or even compiled it.

The physics engine seems great. The rendering engine .. works. But looking at the source there looks like a lot of things you could improve upon. Btw .. i write opengl stuff for a living :p

Firstly .. you need to define a standard polygon winding to use in your engine. Either clockwise or anticlock wise. You don't want to render the backface of poygons. What the point ? :p

Next .. a culling system. Opengl will cull everything outside the view frustum planes, but you will still have to send everything to render every frame, which is wasted clock cycles ..

If you don't have any culling system and you send the entire world to be rendered every frame .. You might as well upload the entire world to the graphics card, either with good old display lists .. or maybe use http://www.opengl.org/registry/specs/ARB/vertex_buffer_object.txt. This will work but won't scale if the world gets more complicated.

Next .. immediate mode. (This means using glbegin glend etc) Immediate mode is the worst way you can pass data to opengl, due to the high cost associated with the function call overhead. It's fine for a thousand or 2 vertices, but once you start pushing more it'll start to become a bottle neck. Ie immediate mode scales badly. You wanna use indexed arrays or just simply vertex arrays. The particle rendering looks like it could easily be changed to use vertex arrays. Just put all the data in a giant array and send it off to opengl. One call instead of .. potentially thousands.

There's no point in adding like, reflections or shadows if the engine is so unoptimised. It will just scale really badly.

The lighting. Opengl per vertex lighting is stupidly fast on modern hardware. You really want to pass 1 normal per vertex and not 1 per face. That way you can interpolate the normals between adjacent blocks. That will stop the flat shaded look and give a more natural feel to the lighting.

I hope these comments are useful, thanks for a great game

Thanks for the comments.

A few ones are also in our TODO list, in fact we have a "full opengl core rewrite"

About the lighting. If i understood right you mean we should trash the vertex lighting and use instead the perpixel ligthining? It's really so fast? I'm not sure about that.

Also i 'd like Raydium would support OpenGL3, but we'll see what have to say Xfennec (the father of the beast).

no i didn't say trash vertex lighting
and yes it really is that fast. A lot of older hardware is optimised to do it really fast.

The problem is just the normals. If you give one normal per face, each vertex on that face will have the same normal. If you give different normals for each vertex the normals will be interpolated (smoothed) across the surface, making everything look less flat and blocky. With per pixel lighting, everything would still look flat and blocky if you used the same normals. In some cases you might not want to interpolated the normals though.

Per pixel lighting throws up a lot of problems, like what to do with overlapping lights. Lower end cards dont support loops in shaders so what do you do with more than x amount of lights ? The solution often was to blend the result in the colour buffer which doesn't do nice things to performance :p

Hi,

You're missing a few things Raydium does not use immediate mode, since it use compiled display lists. This is not, for sure, the fastest way to do things, but it's currently the best one for our needs (before the big-core-rewrite-things that may happen one day )

About culling, I've decided to remove it (there's still a few lines of code there and there) because it gives some rendering cost back to the CPU (and this not the way to follow, as modern graphic cards shows) and collides with display lists, vertex arrays, ... The current rendering code is here because it was the fastest of all our experimentations.

To make a long story short, currently Raydium scales quiet well ! And WITH reflections, shaders and shadows You can have a look to screenshots and video of Raydium website, if you want.

The main problem currently with ManiaDrive are 3D assets. They were made by us, not real graphist people That's probably why you've created this post and why you seems to think we only deal with per-face lighting (in facts, Raydium deals with with smooth groups since ages)

the code for particles very much looks like immediate mode ? I'm not seeing any display lists there.



seems to call



you could speed that up a lot if you just packed the data into an array
and used vertex arrays

I don't see any glEnable(GL_CULL_FACE) calls. The default value is false for GL_CULL_FACE so you must be rendering both sides of surfaces, which will affect the fill rate, and generally slow things down.

I very much like the idea of block based system you have. I'd probably make a display list out of each re-usable block. So if you had a 1000 blocks you'd have 1000 calls to draw display lists, which is perfectly acceptable. But I would also sort the blocks by type, or more importantly by texture ID. So that you don't have to switch textures for each block. You'll get a good speed up doing this.

Maybe some sort of culling system would be more important for the physics engine ?

Exact, as for a few other things like OSD. But 95% of rendering is done using compiled display lists (see object.c).


Test it by yourself, you'll see that the gain is very low (since it's only a matter of fillrate, not polycount)
It was a choice made at the very beginning of Raydium, and now, a lot of 3D models uses double-sided triangles, saving quiet a few triangles per model.



Not sure what're talking about, but ManiaDoes does compile all track assets in one 3D model (see mni_generate() in mania.h) so we can use our regular "sorted texture" renderer, reducing texture context switches.


Done, thanks to OPCODE, but physics culling have nothing to do with rendering culling, for sure !

I have a question ... do you think that Raydium is so slow for asking so much questions about performance ?

well speed is not really an issue for me
i have a pretty fast pc 3gig core 2 duo quadro gfx card etc ..

but well maybe this picture will give a clue as to what i do ..


in stereo mode it seems to be able to slow it down to 40 ish fps which is quite some achievement on my pc So yeah, I think theres definitely room for improvement. I just like tinkering with 3d engines. Stereo mode also gives clues as to how well the engine scales.

I hope to give constructive critism, rather than nagging complaints. That's all. I love this game, it's awesome. Especially the physics.

There should be a problem somewhere (video driver ? VBL ?) since we are able to achieve something like 60+ FPS on a GeForce 2 GTS with a Athlon 1 Ghz ... definitely not a super-fast computer, isn't it ?

Raydium can be quiet slow in some areas, for sure, but the way ManiaDrive use it is very -very- straightforward and soft. For example, the game works even on open-source driver for radeon cards and even some intel ones, even if we were only planning proprietary drivers at the beginning.

Anyway, patches are welcome

... and happy new year !