Thinking about Rak3D

RakNet is nearing completion. About the only thing it doesn’t have is a cross-platform lobby system. I’m not really equipped for consistent cross-platform development, but I think this will be a good next feature.

After that I’m considering writing Rak3D, an easy to use 3d graphics engine in the same spirit as RakNet. There’s a lot of graphics engines out there already, but as I’ve seen they are all deficient in at least one of these 3 ways:

1. Too low level such that unless you are a graphics programmer already you won’t be able to exploit the best features
2. Lacking in integrated tools, or the tools already there suck
3. Slow

The best designed of the ones I’ve used is, in many ways it reminds me of RakNet, though it lacks the features of Ogre 3D.

The goal of my 3d engine would be

1. To better learn graphics programming myself
2. To provide all the common ancillary features people need (GUI, exporter integration with built-in scene view, animation sequence tool, debug output, predefined shaders)
3. To be easy to use such that you really don’t have to be a graphics programmer to get nice scenes.
4. To perform complex operations and optimize them internally, relieving the user of this burden.

I would do this with two layers. The first layer would be more low level and an analogue to the 3D engines already out there. The second layer would make decisions as of a necessity, using the first layer for this, and is intended to be what most people would use, with the first layer as a backup.

4 replies on “Thinking about Rak3D”

interesting. My thought on this would be that it would be more productive to make a package for irrlicht or ogre that is a higher level api. More of a toolbox of one liners that do lots of complex things incredibly simply without having to start a new engine from stratch. Which to be honest sounds like a bit of a waste of time, unless you want to learn low level gfx programming of course.
Also a highlevel toolbox for physics would be great too. For example I use Newton and high level collision functions would make it alot simpler for most situations. I teach ogre and newton with C# so I know which bits confuses non-programmers 🙂

You have good intentions, but I also teach 3D graphics programming and you can never simplify the “engine” to something that a person can pick it up and make Gears of War from it in a month.

Simplifying physics/collision will go a long way. Most of my students understand the 3D/graphics side(I see lots of pretty models + environments), but struggle with the 3D collision which is a very difficult topic.

As for tools, there is no one universal set. Every game needs to write their own due to different metadata requirements (COLLADA + FBX deal with visible data but not data for AI + etc). Such is life…

My approach to simplification is to provide user level functions rather than engine level functions. A user level function provides functionality, such as StartRenderer() or RenderToTexture(). An engine level function simply abstracts away some complexity, such as SetBackbufferFormat() with some enumerations and some such, while still requiring that you know internally what backbuffer formats are, and what you should use in what situation.

If you are writing a hardware abstraction layer, such as Direct3D, then engine level functions are best. But if you are writing an engine meant to be used directly in games, the engine should be concerned with what the user wants to accomplish, and do its best to achieve that, using defaults.

A related problem is where functionality is exposed that does not work by default. In an engine I am using right now, if you create a camera and just use it won’t work. You first have to set the FOV and a few other things. If you use the camera without doing this you just get an empty texture, with no indication to the user as to why.

Startup(), Render(), ActivateBloom(), ActivateHDR(), should all be single functions with few or no parameters, and they should work in all situations, or if they won’t work they should immediately indicate why. No engine that I am currently using or have used has this level of simplicity.

“Startup(), Render(), ActivateBloom(), ActivateHDR(), should all be single functions with few or no parameters, and they should work in all situations”

Should… but in my experience everybody wants to customize things like Bloom/HDR/Vertex+Pixel shaders. The problem with OGRE is that it is too high level at times(SceneManager + Particle Systems being too inflexible) and Irrlicht looks very low level (ala RenderWare).

The hardest part about 3D programming is not the graphics – that’s actually the trivial part. Most of my student produce beautiful looking games with zero gameplay. They struggle with creating collision meshes, tagging it with metadata, raycasting, triggering sounds when the character walks over grass/water/ice, AI pathfinding on a pathfinding mesh, dealing with physics-based cameras, general physics + collision of everything… Billions of small details.

I harp on tools being the achille’s heel of all game development. How do artists export models + animation + metadata to a game engine? And how does the programmer use this data for AI + physics + sounds + gameplay?

I’d base a new graphics engine on how XNA has gone about it. They use .fx and .cgfx files to deal with shaders + compositing. FBX to deal with models + animation. There’s also a sound effects designer as part of XNA/DirectX.

Leave a Reply

Your email address will not be published. Required fields are marked *