What are the plans for Irrlicht 1.8 and further?

3DModelerMan · Post by **3DModelerMan** » Sat Sep 11, 2010 9:43 pm

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 · Post by **devsh** » Mon Sep 13, 2010 8:14 pm

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 · Post by **ent1ty** » Mon Sep 13, 2010 9:15 pm

IMO with your experience you can create it on your own

3DModelerMan · Post by **3DModelerMan** » Tue Sep 14, 2010 2:00 pm

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 · Post by **vectorcorpse** » Tue Sep 14, 2010 5:40 pm

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 · Post by **3DModelerMan** » Wed Sep 15, 2010 12:48 am

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

Mel · Post by **Mel** » Sat Sep 18, 2010 3:52 pm

vectorcorpse wrote: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 · Post by **stefbuet** » Sun Sep 19, 2010 11:59 am

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 · Post by **Brkopac** » Tue Sep 21, 2010 9:05 pm

*cough* stl containers *cough*

slavik262 · Post by **slavik262** » Tue Sep 21, 2010 9:30 pm

Brkopac wrote:*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 · Post by **Brkopac** » Tue Sep 21, 2010 10:46 pm

slavik262 wrote:
Brkopac wrote:*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 · Post by **CuteAlien** » Wed Sep 22, 2010 12:18 am

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 · Post by **greenya** » Tue Oct 12, 2010 10:39 am

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 · Post by **loki1985** » Tue Oct 12, 2010 11:49 am

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 · Post by **CuteAlien** » Tue Oct 12, 2010 3:43 pm

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 :-)