• What is the Irrlicht Engine?
• There are lots of other 3D Engines available. So what are the advantages of the Irrlicht engine?
• Can I use the engine in a non open source commercial product?
• Can I create my game using Irrlicht as game engine?
• How can I make contributons to the engine?
• Why is the engine so fast?
• How many polygons is the engine able to draw?
• I've a problem with my code, could solve it for me please? I get no answer in the forum.
• What does 'Irrlicht' mean?
• Can I join the Irrlicht Engine team?
• Is there no CVS?
• How can I access the Subversion server?
• What will be in the next release of the engine?
• When will be the next release of the engine?

The engine is a quite flexible graphics engine, and it is possible to write lots of different applications with it. Some are: complex 3D simulation applications, first and third person shooter games with indoor and/or outdoor scenes, real time strategy games, 2D games, ...

For more informations, look at the features page.

Yes you can. The engine is open source and totally free. You can debug it, fix bugs and even change things you do not like. And you do not have to publish your changes: The engine is licensed under the zlib license, not the GPL or the LGPL. Look at license for more informations.

Of course you can, it's easy.
But please note: Irrlicht is not a game engine, it only does graphics. For a game, you need a bit more, like sound output and maybe networking and physics, and tools such as a game level editor. You are free to choose any other library to do this. But to make it easier, there are libraries and tools made by us which are independent of Irrlicht, but easily integrate with Irrlicht engine projects. For example, there is irrKlang, a free 3D and 2D sound engine, or irrEdit, a free 3D world and level editor. See the toolset page, the wiki or the forum for more informations and help about this.

If you've wrote your own SceneNodes, image or mesh loaders or further extensions to the engine, just send them per mail to me or post them into the forum. I will have a look at them and consider to put them on the homepage or even into the SDK of the engine.
There is a tutorial available on the tutorial page, which shows how to extend the Irrlicht engine. If you want your addition to be merged with the development branch, please also try to adhere to the Irrlicht coding rules.

The Irrlicht engine was created because no available 3D engine satisfied my needs. I wanted an engine which had some awesome features, and no engine wich was available featured these things:

• Easy to use. All standard things and all cool special effects of the Irrlicht Engine are able to be used without the need to study its documentation for days. For example: To start up the engine, load and show a complete quake 3 level needs only about 6 calls to the engine and about 10 lines of code. Just take a look at the tutorials and examples included in the sdk.
• Flexibility: The programmer is able to change and influence almost everything in the engine although it is that easy to use.
• Extreme stability. Most libraries for realtime applications crash when the user does something the library programmer did not expect. This is different in the Irrlicht engine. It prints out a warning to (debug-)log and continues, always trying to keep on running.
• Fast as lightning. Because speed is always an issue with 3d engines.
  Lots of built-in importers. The engine is able to directly load lots of common file formats because I did not want to use converters or exporters, increasing development time. (.3ds, .md2, .obj, .pk3, .ms3d, .bsp, .x, .bmp, .tga, .jpg, .psd, .pcx...)
• Platform independence. The engine is available on multiple platforms.
• API independence. Because there are always some driver issues, the Irrlicht engine supports more then one API. Currently there is an OpenGL, Direct3D8 & Direct3D9 device, a null device and two software rasterizers. The devices are able to be switched during runtime.
• No dependencies from other libraries. The engine needs no other libraries and sdks to be installed. Not for programming with the engine and not for using the engine as end user. E.g. The engine will also start up if no DirectX is installed on the end user system.
• Detailed Documentation. With lots of examples and tutorials.
  All the standard stuff. It provides you built-in tools and utilities you will often need in 3D applications. Things you do not always want to code again when doing a new application. (GUI System, Font System + Tools, fast 3D Math, Containers, ...)
• Open source. The engine is fully open source and totally free. You can debug it, fix bugs and even change things you do not like. And you do not have to publish your changes: The engine is licensed under the zlib licence, not the GPL or the LGPL.

You can take a look at the features page of the Irrlicht engine, for a more detailed description of most features.

Lots of people are writing mails to me, telling me that they've evaluated some 3d engines now and are wondering why the Irrlicht Engine is that fast, faster than the other ones. To be honest, I don't know the exact reason. But there are some possibilities:

• The Irrlicht Engine does not use that conservative culling algorithms like most other engines do, which works better on todays 3d hardware.
  It uses 16 bit textures by default (but all other formats are possbile too) which enables the engine to transfer and/or display textures 2 times faster than other engines.
• The engine does not relay on lots of other slow libraries, almost everything is implemented directly inside the core of the engine.

There is no limit. Okay, almost none: The only limit is your hardware. So push out as much polygons as you need, as long as your game is not getting slower.
Some people keep asking me why there are only 10000 polys in the techdemo as maximum. This is only because I did not want to include a huge quake 3 level, making the SDK download size bigger. If you want to see the engine render more polys, just replace the demo level with another one, and see for yourself.

Sorry, but I don't have the time to debug your application. Lots of people are sending me their code because they are not capable of using a debugger, and I am not able to check every program which is sent to me. In most cases it's a problem in your C++ code and has nothing to do with the engine. Just start your debugger and find out where your application crashes. Or if you don't know how to use a debugger, you could print out a
text before every line, to find out at which line it crashes.
The most common reason, why you don't get any help in the forums is because you did not specify your problem enough. Just pasting 100 lines of code into there and writing "it crashes somewhere here, could you solve it for me" is not enough. Hey, you are the programmer, and at least 60% of the programming time is spent debugging the code. Well, this is how I do it, and the 60% value may be higher or lower for other programmers, but I think you get the clue. Just try to find out by yourself what you did wrong. You'll learn more from this then if you let it be fixed by others.

Irrlicht is the german word for a fairy-tale creature which glows and flies, and can be found mostly in the vicinity of swamps. I think the correct english translation is "will-o'-the-wisp". Also, the word "Irrlicht" is the composition of the two german words "irr", meaning "mad" and "Licht", meaning "light". The Irrlicht Engine is being developed in Austria (country south of Germany, not Australia) and so I think 'Irrlicht' is a cool name, although non german speaking people may not know how to pronounce it.
Because lots of people asked me how it is pronounced, I uploaded a .wav file, in which you can hear a girl saying 'Irrlicht Engine'.

Basically: No, sorry. We would like to keep the Irrlicht Engine team small to keep everything clearly arranged.
However, there are exceptions. If you for example create a cool/useful/huge addition to Irrlicht and we think it would be easier to maintain this part with you joining the team, and you would like to do this too. Example: It would be cool if Irrlicht would run on the Mac platform too. (It already does, just an example.) Several people created partial working ports and sent them in as diff file, but they were incomplete and at that time there was no version control system for Irrlicht and it was not easily possible to synchronize the code, and we didn't accept new team members then. But that's changed now: If you created a working, Mac port according to the Irrlicht coding rules, would like to share and maintain it and also like to join the team, then just send your code to niko. That's it.
Please note that we are getting really a lot of requests of people who want to joint the Irrlicht Engine team (about 4 or 5 per month). So it is really difficult to choose, because we would like to keep the team small.

If you are creating a patch for Irrlicht and want it to be merged with the development branch, please try to follow these few rules:

• Don't add dependencies to other libraries or at least only if really, really necessary.
  • Don't use the STL, use the Irrlicht built in containers instead.
  • Don't use platform specific functions, use the internal os:: namespace for that if there is no other way to do what you need.
• Always keep in mind that Irrlicht must be compileable on lots of different platforms and with several compilers.
  • Don't use special compiler extensions and try to adhere to standard C++.
  • Use the Irrlicht types like f32 and u32 defined in irrTypes.h.
• Try not to break the existing interface if it is not really necessary. Only change current behaviour of the engine if necessary. People should be able to upgrade to new Irrlicht engine versions as easily as possible. If you are doing this anyway, it would be a good idea to discuss this with niko before.
• Try to adhere to the existing Irrlicht code style.
  • Interfaces visible from outside start with I (e.g. ISceneManager), implementations with C (CSceneManager), structures only for holding data with S (SVertex3D).
  • Methods start with a lower case letter, member variables with uppercase letter. (e.g. ISceneManager::addTestSceneNode(), ISceneManager::ListOfSceneNodes ).
  • Public methods of interfaces have default parameters where useful.
  • Add doxygen documentation to new or changed methods. If you did a bigger change to Irrlicht, it would also be nice to document this in the file changes.txt
  • Use the C++ line breaking style, not the one used by Java coders:
    

    Good	Bad
    for(foo) { // bar }	for(foo) { // bar }

  • There are some other few rules, but the ones above are the most important ones, for example it is a good idea to use spaces, newlines and tabs as often as possible. Just try to make your code look like the existing one.
• Always check for errors, prevent crashes and wrong behaviour by validating pointers (check if they are not null) and input parameters. Log an error message and keep on running instead of stopping execution at all cost. There are of course exceptions like performance critical code like triangle rasterization in software mode.

That's it, have fun coding.

Irrlicht is now hosted by a subversion server. All data in the CVS server is pre 1.0 source. But if you still want to, you can access it via :pserver:anonymous@cvs.sourceforge.net:/cvsroot/irrlicht
Modulename is 'Irrlicht'. For a detailed description, see this sourceforge manual page.

You can access the subversion server via https://irrlicht.svn.sourceforge.net/svnroot/irrlicht/trunk, online online repository browsing works too.

Take a look at the development page or my blog, I am updating it from time to time with development news. You will find a short list of features, which you can expect to appear in the next version of the engine.

When it is done. This is only a open source project with one programmer, and I don't get any money for it, so I don't even have real deadlines. Time has shown that I need about 1-2 months for a minor release, meaning for example going from version 0.4 to version 0.5. Usually I am announcing the coming of a new release one or two weeks before it is done, and posting some screenshots of new features on the news page. So please don't send me emails asking when the new release will be available: In most cases, I don't know myself.