Irrlicht Engine

I wanna see good bsp stuff in irr 1.6. MOHAA, Enemy Territory, or RTCW .bsp support? It'll be great feature.

here is reference topic where you can found mohaa .bsp loader code
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=32392

and here you can grab RTCW source code (with rtcw .bsp loader)
http://returntocastlewolfenstein.filefr ... file/;8508

and what about natively joypad's force feedback? actually you can implement it with OIS... http://sourceforge.net/project/showfile ... 5&abmode=1
but it would be cool if you can handle it only with irr!!!

I'd implement floating point textures, multirender target and support for 8 textures before Force feedback

Malgodur wrote: RTCW .bsp support

Whoa, goodness me, rtcw bsp loader is out ?

MRTs, Floating point textures and instancing would be the best to go for because they woud make irrlicht lighin fast^2

devsh wrote:MRTs, Floating point textures and instancing would be the best to go for because they woud make irrlicht lighin fast^2

Hmm, strange. I tested it and all of my apps were 10% slower instead

devsh wrote:MRTs, Floating point textures and instancing would be the best to go for because they woud make irrlicht lighin fast^2

It's dependent of current environment, but MRTs, FP formats, Cube and Volume textures and *.dds file support (compression, mapmapping etc.) will be very, very useful stuff.

1) Hardware Skinning - I started learning vertex shaders(never worked with them), but it turns to a herculean task for me at this time. This will give a nice performance boost, like in sio2`s examples. I PM-d him if he could release the source, but he didn`t even bothered to reject my request, so I`ll keep learning and trying.

2) Some build-in shadow implementation for Xeffects` shadows with adjustment for the size and filtering (quality vs speed).

3) Maybe some culling techiques for not rendering all that`s beyond the wall and on...

To implement Shadow Mapping in Irrlicht, in general, irrlicht should have an unified structure for materials that suported shadow mapping. Like built-in shaders, in the same fashion as the fixed function (SOLID, TRANSPARENT... etc). because if not, i think it would become quite ineficient.

How does Hardware Skinning work?

It will be great that irrlicht can render bezier surface & mesh.

and what about to finish a "100% compatible with autodesk collada (*.fbx)" mesh loader?!
so you can export meshes from ALL the autodesk program!
it would be great U.U

Well. I guess the devteam can implement all these features during their lifetime, if they try to do it in the current way. A more modul/plugin orientate system may help to seperate the core dev tasks from features tasks and provide a more simple way to allow and distribute extentions (less code snippets and more allready compiled plugins(packets)).

i think the most important issue (and hardest one at the same moment) is multithreading. OK, not every part can be made threadsafe, but most could be. also, moving texture upload to a manager which could be configured and controlled by the developer would be highly useful.

I have allready done some things with threads and i think that they wont give a such big boost for an api like irrlicht. Only for backgroundloading but else....

i got dream, about deferred shading.
lightings and shadows, whats beautyful .

maybe Irrlicht 2.0 (will be minimum requirements, ShaderModel 2.0 or better) ? .