What are the plans for Irrlicht 1.8 and further?

[christianclavet]

Thanks aanderse, I did not see it. Now I do, this will really be useful to me as I want to load big scenes... Loading non-stop without a refresh will make the application seem it's frozen.

[aanderse]

Thanks aanderse, I did not see it. Now I do, this will really be useful to me as I want to load big scenes... Loading non-stop without a refresh will make the application seem it's frozen.

glad to hear, hope this helps you out

[Nalin]

- Optionnal support for truetype font rendering (I mean a IRRlicht compiler flag that enable the support, not an extension)
- IS there a UTF8 conversion available when loading XML strings? (UTF to widestring?)

Gotta use my Irrlicht patches:
http://irrlicht.sourceforge.net/forum/v ... =6&t=37296

[Andreas]

I want to congratulate you guys, you are making an excellent work! I just prefer to have a SDK that is stable than a SDK that is full of new features and bugs (New features rarely comes without any bugs).

I just wanted to add another vote for this statement! I often read threads querying new features which then only work on a specific platform or need the newest generation of graphics cards or whatnot... I for myself use irrlicht for hobby projects and am happy with the current direction of delivering a stable and platform independent library. So, thanks a lot to the irrlicht crew for your excellent work!

// Scene
- IRRlicht native animated mesh format, so we could work on meshes, change their attributes (textures, materials).
- Axis oriented billboards (fake trees, decors and perhaps imposters)
- An easy way to use decals.

Those are exactly the features that i miss the most. So if they would make it into the engine some day, i'd be very happy.

[3DModelerMan]

Yeah those three could be really nice. Although axis oriented billboards are pretty easy to write yourself.

[fmx]

- IRRlicht native animated mesh format, so we could work on meshes, change their attributes (textures, materials). I'm really happy that we have savers, but it would really be cool to have an animated mesh saver also. By the way is there a way to "edit" animation data?

This is not actually the problem, because once an animated model format is loaded correctly into irrlicht (.B3D, .X, or whatever else might come in the future) anyone can "edit"the animation and model data as they need to (though it can become tricky without any visualisation hints )

Writing out animation and keyframe info into .IRR files should have been trivial, I'm surprised it hasn't been implemented yet

[Andreas]

This is not actually the problem, because once an animated model format is loaded correctly into irrlicht (.B3D, .X, or whatever else might come in the future) )

Well, that's exactly my problem at the moment. With blender 2.5, gandalf's b3d exporter doesn't work, and the X exporter of blender didn't work for me, either. And even with blender 2.4 it was no trivial task to get an animated model exported correctly so that it could be used in irrlicht, at least for me...

So my hope would be that a native, animated mesh format could be added to irrlicht and the excellent irrb exporter some day, and all problems are gone forever.

[3DModelerMan]

Yeah, importing models into Irrlicht is a pain. When I get around to writing my engine I'm just going to write a tool that converts FBX files into B3D so that when I copy the art assets with my automated build system the FBX files in the build are converted to B3D. One thing I think would be nice for Irrlicht to have is a replacement shader function. You would be able to set a replacement shader that all objects would be rendered with until you called SetReplacementShader(0) to go back to the regular shaders.

[fmx]

If you are having problems importing animated models correctly into irrlicht, then asking for a new custom model format isn't the solution because then somebody would not only need to create new plugins for all the 3D modelling tools, but would also need to maintain them in the future.
That is a lot more work and could take a very long time to reach stability.

IMO the COLLADA .DAE format is the best option for 1.8 (or 1.9), since COLLADA is already implemented for static models and is supported by almost all tools.
I will look into it as soon as I finish with my current project, I plan to create a new techdemo with irrlicht soon to experiment with a couple of other things

[hybrid]

Unfortunately, collada loads very slow. So it's not really usable for in-game assets. Same holds for fbx.

[fmx]

Yes I agree those are very slow at load-time, but both Andreas and 3DModelerMan are talking about problems just getting their models to import correctly in the first place, which was why I suggested the short-term solution of fixing up atleast one other common format for animated models, instead of inventing a solid binary format which (although ideal) could take a long while to become useable because of dependance on plugin writers for all the modelling tools out there

Writing out binary files for fast loading purposes (eg, games) isn't much of a big deal once the data is loaded correctly in ram as a skinned-mesh node, but the first step needs to be improving irrlicht's ability to correctly import animated models from any potential modelling tool without causing headaches.

But if I were to give one reason why COLLADA or FBX should be added fully ASAP (for 1.8 or 1.9):
both of the current formats for animated data (.X and .B3D) are not good enough, apparently

[3DModelerMan]

Mainly the thing I think Irrlicht needs to be able to import better for models is the material settings. They aren't consistent (or maybe it's the exporters). Also, it would be nice to have some flags/settings for imports so that we could set custom scale factors and the like. And packed textures would be cool too.

[devsh]

I'd love to see texture streaming in irrlicht 1.9

[3DModelerMan]

Yeah texture streaming would be nice. But compressed textures are more important and they're missing.

[devsh]

I wouldn't say so... you can get around compressed textures (less VRAM) by using 2x or 4x smaller textures, but you cannot get around loading the whole GTA SA world with like 6GB of texture data on a 512mb machine