Irrlicht Engine

What does everyone want in Irrlicht 2.0?

I want truetype font support merged in . Bitmap fonts are gross.

http://irrlicht.sourceforge.net/phpBB2/ ... php?t=3995



Maybe we can get some of the better patches merged in?

http://parsys.informatik.uni-oldenburg. ... /irrlicht/


Suggestions? Niko and the team are gonna do whatever they are gonna do, but we can at least post some ideas.

I hope that these things will go into Irrlicht 1.1 and not in 2.0
Looking on the enormous development from Irrlicht 0.1 to Irrlicht 1.0 there have to be really some major enhancements to be done for 2.0 Good idea to collect these things here!
Ok I have something for the new releases besides large terrains and such: Level of detail for arbitrary meshes and a reorganized render pipeline to support several materials, multiple passes and structured support for image manipulations of the final render image (i.e. an API for the postprocessing).

A better filesystem would be nice.
- Support for virtual folders. So you can for example set a base directiory (base:) to any directory and refer to files like base:file. Also it could be possible to set several directories for a virtual folder so that base for example would search HD and CD for files.
- Functionality to get the directory in which the executable is located (not that trivial when trying to be platform independant).
- Support for all formats to put textures and models in different directories (working for some, but not all so far)

Better support for complete workflow from modeler to engine. Depending on what i need (alphas, bumps, animation, etc) i have currently always to try a lot until i get models working in the engine. It nearly never just works. This is not so much about better support for different formats (which will improve anyway and will never be perfect), but about better documenation. Maybe this could be done in the wiki (so no need to wait for 2.0). Just a table with modelers (blender, maya, max, ...), features needed for the models (lights, alphas, animations,...) and a description for the best way to get that models+features displayed in the engine.

I'm amazed nobody said: Spot lights, and better culling/collision/animation handling

More light nodes are available in IrrSpintz, so just an integration of available features.
Do you have suggestions for new culling algorithms and the other topics?

cal3d style access to animation data.

I've done portal culling, hardware occlusion culling, and precomputed PVS for Lightfeather. If anyone wants to discuss culling algorithms, send me a PM or catch me on IRC

I think that Acki's animation should get in, because for now you for example can't play animations with different "phase"

I'd love to see a single unified mesh format. Right now, Irrlicht supports a ton of different mesh formats which is wonderful in theory but each one has its own little problems that are different from each other one and supporting so many formats in-engine makes the code and architecture a bit of a mess. It would simplify the engine and the art pipeline to just have one standard mesh format. Convert the existing mesh loaders into offline conversion tools to the unified format (either settle on XFile or some new custom mesh format).

That's asking for a lot and I know some people prefer to have the engine support a billion different formats out of the box, but that's what I'd want in an ideal world.

I think the SceneManager should become just that, a scene manager. And that you can add and remove Scenes to the scene manager, so that it actually manages scenes, not nodes. Each scene would manage its own nodes, and the scene manager would call the drawing function of the active scene. this would make the engine much more friendly with game creation since each game state could have its own scene.

gmcbay wrote:I'd love to see a single unified mesh format. Right now, Irrlicht supports a ton of different mesh formats which is wonderful in theory but each one has its own little problems that are different from each other one and supporting so many formats in-engine makes the code and architecture a bit of a mess. It would simplify the engine and the art pipeline to just have one standard mesh format. Convert the existing mesh loaders into offline conversion tools to the unified format (either settle on XFile or some new custom mesh format).

Seconded!

But all static meshes share a common interface with almost no extensions. So there is one mesh type for them, with several loaders available. The animated meshes have to get a simplified API, such as frame animated and bone animated meshes. What other things should be changed?

Static meshes don't really matter. As you said, they just load into meshbuffers and then all is well. But, yes, I mean the animation system. Now each animated mesh type X, MS3d and MD2 have there own interface appendages. These should be unified. And imho before a version 2.0.

For version 2.0, I have a custom file format on my wish list. A custom format allows control over the design of it.

They allow for individul features, that sets the engine apart.
So far the features of Irrlicht are dictated by the file formats in use. With a custom file format you can not only implement new features to the engine, but also store those in the model files. For instance, Ogre has relative blendable vertex transforms as a new vertex animation type added to the engine, to supplement skeletal animations. This is useful for facial animations, where using bones is not the most comfortable way, damage to cars and others. Without its own format, this were difficult, as none of the formats in irrlicht support this as far as I know.

Custom file format allows for faster loading.
Since you can tailor the format to the engine's data structures (after having them designed properly) the files load faster. And you can put precomputed informations into them for even faster setup. (Seel below)

The file types supported aren't suited for todays real-time graphics.
3ds and obj for instance were never designed to be used in a real-time engine. They are simple interchange formats. Most of the formats are lacking important features like multiple UV sets, precreation of LOD / edge lists / tangent space bases. In a custom format you don't have to bother, you can design it to make this addable. Eventhough some of these can be computed at runtime, it doesn't have to be necessary. They can be created once and then saved in the file.

I guess these are some of the reasons, why most (if not all) commercially successful engines use their own format.

One of the more difficult parts of implementing a custom format is to get it started. The modelling tools allow export of the other types, but not a new one. Till community creates the exporters, one can still use the current loading code as the basis for converters.

more linux love:
dynamic light on open gl terrain node
get rid ov the x11 key/nvidia errors

Better movement system.

Instead of being able to set a position, or increment a position (translation), it'd benice for an object to move relative to its rotation.