Irrlicht Engine

IGUIElement should derive from ISceneNode. Why limit the GUI to 2D? You can always do 2D in 3D, but not the other way around.

I'd like to see normal maps that are affected by more than two lights (maybe 5?)

Write a shader that takes as many lights as input.

I don't know the first thing about shaders, much less complicated ones like parallax maps.

hmm.. maybee a better documentation with little code exampels(I konwo this is a huge thing, but it would help beginners lik me a lot!)

another thing: a IGUISaveWindow or something like this...
*edit* IGUIFilesaveDialog

a light manager.

HERE HERE!
8 light limits are so annoying

I have checked out http://www.freeworld3d.org/ and intend to use it for a terrain system based on Irrlicht. It would be nice if this one, or another existing editr, could be bundled. Maybe a cooperation with the guy who makes it? I understand it's also a one man project, so why not work together

Baal Cadar wrote:Ogre just uses cegui (and its own overlays in parts), which runs fine with Irrlicht too. Next cegui version 0.5 will be released soon and under MIT license instead of LGPL. Yet another reason gone not to use it.

Check it out.

Isn't that a good thing?
to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software

Doesn't this mean that it can be released with Irrlicht under Irrlicht's licensing?

Personally, the only thing that irrlicht really needs at this point, in my eyes, are:
1. No more 8 light limitation
-pretty self explanetory

2. Support for multi-pass [external] shader scripts.
-you'd be able to completely change the look of an object without recompiling.

3. Moderately skinnable GUI system.
-Skinnable means that it will be able to look however you want. The GUI element support is very nice.

The engine is really fast and easy to use. These options would make the engine look and feel like a commercial 3d engine.

I would like to see a better .NET wrapper support, since i'd like to stick with irrlicht and not switch to ogre just for that and there isnt really any good alternative out there ( considering not only engine quality and pricing but also things like community, number of created tools etc. ).

Besides that - set an unified model format. No md2/3 , ogre, maja, lwo, lalalala stuff anymore. Support for it is one thing, but getting the most out of the model is another, and with supporting large number of models the task gets too large imo.

xhrit wrote:a light manager.

There was a post awhile back from Niko about a software light manager that had abouts 200 lights going at once; I also think he said something about a demo. . . Mayhaps we should ask what happened to that

EDIT : I must also agree with Sh1ny on a unified mesh format, I think this would help improve Irrlicht vastly, my 2¢
EDIT EDIT : Multipass shaders again would be something else that would be very nice to have, but to me it is not as big a deal to me as a light manager or unified mesh formats.

if your talking about 1.1 id go with opengl 2.0 support and built in direct3d8 and 9 so u dont hve to compile your self and in 2.0 id like to see direct3d10 or XNA which should be out around 2007

master123467 wrote:if your talking about 1.1 id go with opengl 2.0 support and built in direct3d8 and 9 so u dont hve to compile your self and in 2.0 id like to see direct3d10 or XNA which should be out around 2007

Irrlicht has OpenGL support for years since OpenGL is backward compatible you can always use newer versions with older apps. So talking about OGL 2.0 does not really make sense. A major feature of 2.0 is shader support and Irrlicht had this already for some while - as an OGL extension which simply means it's not yet in OGL core.
The d3dx devpak for dev-cpp only contains debug libraries which are not allowed to be distributed so it would need a better SDK for this AFAIK.
Niko already wrote about d3d10 on his blog, so check it out. But it's currently just the same as with OGL 2.0. It's a question of features, not versions.

arent the d3dx9d.dll the debug and the d3dx9.dll regular as the extra d at the end stands for debug

because i hve in my dll directory in devcpp microsoft direct3d debug dll's and the d3dx9.dll and d3dx8.dll tht dont say microsoft direct3d debug