Irrlicht Engine

Agrif Multipass is ussually used to bypass maximimum instructions limits/grass shaders rather than extra textures bc when using multiple textures the textures may need to interact with each other directly moreover multipass erquire double the number of faces to be rendered.

I also request better collision detection and better createCollisionResponseAnimator 'cause in some case the collision is not calculate correctly and the objs can trought the walls (on my computer hightprecisionFPU set to true attenuates but it doesn't eliminate the problem)

Add the movie player in texture thing.

This is not possible as it is either windows only or requires an additional library. But it's another good thing to merge all this into a pretty well designed scene node and create a contributions archive to simplify adding those features.
Anyone volunteering?

omaremad: I don't understand what you're saying. In my understanding, GLSL samplers are used for lookup tables or textures. In order to get any texture, you need a sampler to begin with. Every GLSL shader I've seen uses samplers for extra textures.

Maybe we misunderstood each other.

hybrid: Wow, maybe I should check before I change my mind (again). I just tried setting GLSL samplers with my 1.1 unpatched version. No luck . Maybe the patch isn't applied? I haven't checked SVN, but at least 1.1 is patch-free.

Hi,
great idears !!!

And feel free to use my extensions for this !!!

I want a Follow Path animator! I have implement my own one
of course it's better to add it to the next release!

and I wish the x format file loader could be more compatible with Panda X exporter... Usually, complex scene with animations exports would not work correctly, though simple models would be fine.

1) keep Irrlicht slim - 1 dll(or 1 static lib), less than 2MB
2) avoid heavy dependencies on other libs. and keep some neccessary internal components, e.g., simple UI
3) easy to compile, to learn and fast to run
4) confirm to be able to run on low-end machines.

and maybe more important:
5) refine the art pipeline. make Irrlicht load mesh files perfectly at least one file format.

The more features Irrlicht gets the bigger is the dll. You can't expect it to do everything and be 2 MBs

may be it is possible to add heavy functionalities via additional dlls? the only thing is needed is something like plugin architecture in irrlicht core.

for example OGRE consists of several dlls, each represents separate part of the engine

I absolutely despise the Ogre setup. The plugin system and multiple DLLs is a nitemare. I don't want to get into an Ogre/Irrlicht war, but a single DLL is definitely the way to go.

At work we have 3 different projects, each with 60+ DLLs, some of which are shared betweek solutions and it's a friggen nitemare to navigate the code. Not saying Irrlicht would get this big, but it gets the point across. I have to spend 3-6 months evertyime we wire a new Software Engineer teaching them and helping them navigate the code until they are comfortable with it.

Also, I don't understand why the Irrlicht DLL is 2MB to begin with anyways, IrrSpintz release DLL, compiled with VS2005 is 1.17MB( 1,228,800 bytes ).

i think that irrlicht.dll>2mb is not a problem, 'cause the most important things are speed and features and now we have the ADSL, so size>2mb is not a prob. most compilers (like vc++) can increment binary size and speed or decrement both. I think that the right optimizations is the first. i'm versus irrlicht plugin system like OGRE. I don't want to implement water and copy a dll, implement GUI and copy a dll, exc..

Bye

I compiled Irrlicht 1.1 with mingw and then used UPX to get it down to ~0.99 MB.

I think there should be some "#define" 's we could use to compile irrlicht without certain features like specific model and image loaders to lessen the size for those of us who will only be using certain formats in our project.

But if you're using GCC compilers, UPX is the way to go to get your irrlicht.dll downsized. also, remember to use "strip" before compressing it to really get the size down. Also, don't build it with debug and your size will decrease. One of my friends took out the things he wasn't going to use, compiled, stripped, compressed, and got it down to 400KB...

i would never have considered 2mb a "large" DLL. 2mb to me is a negligible file size. i know i've had broadband for a long time, but still. its pretty damn small.

for that matter, why is there always people who are uber-concerned about running on low-end machines? i mean midrange average family pc's is one thing, i see the target-market reasoning there, and in my experience, if you avoid the extra pretty effects, you can get decent FPS on anything 3-4 years old. my work pc for instance is a 4-year old box with a crappy 64mb quadra in it, and it still ekes out respectable performance in most of my irrlicht stuff. how low-end are we talking here? like pentium 2's, 3's? do a lot of people on here really have hardware that is >5 years old??

i'm more interested in extra scene nodes, and more advanced shader support.

also, as has been said, if you are targeting specific hardware, like the xbox for instance, you would definitely want to be modding the dll to remove stuff you don't need. like opengl and the software drivers in that case. also, if you want to stick to one mesh format, and one texture format, which makes sense, you could rip out all those extra loaders pretty easily right? i would think that wouldn't be too hard.

provide such an interface please: ISceneNode::setTransformation(matrix).

this make us able to set the scenenode's transformations by passing a matrix, which will make transformations happier!!
then when I have a tranformation matrix for it, I don't need to convert the matrix to position/rotation/scale!