What are the plans for Irrlicht 1.8 and further?

[3DModelerMan]

slavik262 said that the overload of convert append that takes another meshbuffer has a completely commented out body. Will that be fixed in the next release?

[devsh]

guyz??? How about LoD, like being able to set LoD distances on a mesh and achieving LoD through using separate index buffer for each LoD level and keeping only one vertex buffer

[ent1ty]

IMO with your experience you can create it on your own

[3DModelerMan]

It would be nice to have some sort of tweening feature for meshes. I could try to implement that and post a patch if anyone would like it. Something like: IMesh* IMesh::tweenMeshes(IMesh* meshToTween); and it would just check to see if the indices match, then interpolate the vertex positions.

[vectorcorpse]

i'm probably asking for 2 much, but i would be happy with just 2 new features or even one.

1st and with priority over the other, fixed function projective texture, because with it we could do: blob shadows(any shape and color), bullet holes, blood stains,arbitrary stencils on walls, moving textures across multiple meshes, and many other effects and with minimal performance impact specially on old hardware, it is good for professional looking on games across multiple hardware configurations and a good alternative to shader implementations were a programmable shader simply isn't available.

2nd and backing up 3DmodelerMan and stefbuet would be cubemapping, only at driver level would be enough (of course that even that doesn't get around the texture problem mentioned earlier) it would be a great feature because it would speed up other already implemented features and improve the quality of others like shadow mapping, reflection mapping and many other effects that have a great impact visually.

almost all other new effects can be added via a shader or with a wrapper without big performance penalty and for those a simple update on the tutorials on the wiki page would be enough.

anyway congrats on everyone involved has this is a really great graphics engine, and keep up the good work.

[3DModelerMan]

Yes I would be happy even with just those two also.

[Mel]

i'm probably asking for 2 much, but i would be happy with just 2 new features or even one.

1st and with priority over the other, fixed function projective texture, because with it we could do: blob shadows(any shape and color), bullet holes, blood stains,arbitrary stencils on walls, moving textures across multiple meshes, and many other effects and with minimal performance impact specially on old hardware, it is good for professional looking on games across multiple hardware configurations and a good alternative to shader implementations were a programmable shader simply isn't available.

+1

It would allow to make soft stencil shadows and would make easier the usage of shadowmap buffers.

[stefbuet]

Just a little thing :
We can compile shaders up to EVST_VS_5_0 and EPST_PS_5_0 however we can't ask further than EVDF_PIXEL_SHADER_3_0 and EVDF_VERTEX_SHADER_3_0 to the query feature function from the driver.
How can we know if we can compile with EVST_VS_2_a ? query feature allow us to know either 3.0 or 2.0 but not 2_a.

[Brkopac]

*cough* stl containers *cough*

[slavik262]

*cough* stl containers *cough*

No! Irrlicht intentionally avoids these, since the implementations vary from platform to platform and might not be optimized for real-time code.

[Brkopac]

*cough* stl containers *cough*

No! Irrlicht intentionally avoids these, since the implementations vary from platform to platform and might not be optimized for real-time code.

I was under the impression Irrlicht didn't use them because back in the day the VC6 implentations were atrocious so they created their own.

see. http://irrlicht.sourceforge.net/phpBB2/ ... 402#214402

[CuteAlien]

Don't know if own container still have any advantages nowadays. Not for speed according to my tests (rather the opposite). Maybe for embedded systems? But I think the best way forward for now is to make Irrlicht-containers more similar to STL. For example making sure the Iterators fulfill the requirements for the standard algorithms. If you search the forum - there should be some 10-page thread about this somewhere. I have no problem if someone revives that thread there once in a while :-)

[greenya]

Please add ability to delete (unload) fonts loaded using gui::IGUIEnvironment::getFont(). So it will be possible to regenerate fonts in run-time. This is very useful for scaling for example (when you want resize all GUI including font sizes when window size changes (like this is done in Blizzard games (wow, sc2))). I have wrote small example (in c# with my wrapper), that can generate font on the fly, but i do not know how to unload old fonts

P.S.: because now as i know, fonts unloads only on device->drop() call... correct me if i'm wrong.

[loki1985]

honestly, switching to STL containers (plus maybe dropping the reference counting) would make irrlicht much easier and less special in usage.

i think having smart pointers might be a good idea here.

[CuteAlien]

greenya: Wow, I could have bet we have that already. That's indeed something we should add.

loki1985, the STL thread is here: http://irrlicht.sourceforge.net/phpBB2/ ... hlight=stl

A lot has been said about that already, but don't let that stop you from reviving the thread :-)