Leaving Irrlicht?...

[BlitzCoder]

Yes looking forward to some enhancement with the animation system. : - )

Great work btw on the v1.9 android target , the apk loads nicely and is just less than 2mb w/ the dwarf animation sample.

[Andrey01]

This will be probably a bit offtopic, but I am interested in knowing reasons of disintegrating of the Irrlicht development team. The single active developer and the forum member so far is CuteAlien. The lastest feature release (1.8.0) is more than ten years old. The lastest bugfix release is also already pretty long-standing, of 2021 year. And all commits on the official svn branch are made exclusively by CuteAlien (I browsed lots last commits and all of them done by the same person). What really happened with this project and where did remain developers go?

[CuteAlien]

Each in different directions. Simply life happening. Niko working on other stuff (see ambiera.com). Bitplane got a nice new job, Hybrid started his own company. BlindSide and Nadro finished studying and started jobs and families. In my case life's also interfering often, so there can be weeks/months where I won't find the time/energy for Irrlicht. Thomas Alten is actually still around - if you have any problem with his software renderer (Burnings) then so far he always cared immediately. Also Yoran still helps keeping the Website alive. So I'm not fully alone yet with maintenance.

As for the 10 years nothing released: A big problem was that too many construction sites got opened after 1.8 and none finished. Then people left. So last half decade or so whenever I find time I'm closing those down. And sometimes people (or myself) find new bugs and my todo grows again. Right now I've kinda already given up again on a 1.9 release for this year. But still hoping to get another 1.8 out (with SDL2 added). Thought there's also not that much missing for 1.9 (except spare- time...).

[Granyte]

An other thing that might not have helped is that alot of the non core members that contributed from times to times required features that are not even in the irrlicht roadmap for our own projects.


I know of at least the BAW team and My self that forked away from irrlicht

[CuteAlien]

When you are already drowning in half-finished features and lack people willing to help maintaining the engine, then more feature wishes are a bit of a nightmare ;-) I also got my own wish-list, but always feel pressured to work on open problems. Pretty depressing really and very often ends up with me not getting done anything at all whole evenings even when I have spare-time because my brain doesn't manage to solve the conflict between what I'd like to work on and what I feel I should do first to get another problem off the list.

Note that what BAW (now Nabla) did was pretty cool. But it's no longer the same engine. Which depending on what you need is good or bad. It's pretty good for advanced stuff, but maybe a bit harder to use for beginners (and by their standards I fear I still fall in the beginner category).

Not sure I remember right what you needed. Was it the D10/X11/12 stuff? In which case - yeah, that was another feature someone started and then left. Guess that was meant to be Irrlicht 2.0. I know how hard it was trying to squeeze that into an engine which was build around the fixed function pipeline and it had to break a lot. Still would have been nice. Nadro looked at it a bit, but didn't seem to like the direction it took too much and decided he'd rather wants to do his own branch (but then his life started, etc...). So, yeah - sucks to have no pure shader pipeline and any Irrlicht 2.0 on the horizon anymore, but we can't force (or pay) anyone to work on that. Either someone picks it up or it dies, that's simply how it goes in OpenSource.

[Granyte]

Yes I needed a lot of Dx10 and later features as well as instancing.

My own project is based on the shader pipeline branch and is still close enough to irrlicht that porting back is not an absolute impossibility. If there is an interest for it. I would be glad to help port back features from my fork if there is any interest.

If fixing some of the still open issues could help speed this up I may be able to spare some time for this where is the list of inprogress/open issues?

[CuteAlien]

If there is interest... you are obviously interested :) Basically I can give you access to the branch and you're free to do with it what you want. Thought it's really not that much different from working on your own fork. Except maybe - until 1.9 you still will have to use svn (sorry...) and maybe more publicity due to the famous Irrlicht brand? Maybe also a bit easier to merge stuff from trunk if you need anything from there. I don't know if that means it will become Irrlicht 2.0 some day. Sadly so far I know exactly nothing about that branch, except for it's name. I always planned to take a look at it after the Irrlicht 1.9 release :-(

Open issues - it's a bit of a regularly changing list (like when I hunt some bug/problem I notice in my projects, so today for example I worked on something not on list). For 1.8 I work on back-porting an SDL2 patch to Irrlicht 1.8 with a bunch of changes (the original patch replaced the SDL1 device, but that one is still needed on some platforms by some Irrlicht users). And reason I backport that one to 1.8 is that Debian guys start complaining about SDL1 and another 1.8 release is easier to do than 1.9 (and sdl disabled by default so won't break compatibility).

1.9 list currenlty looks like this (+ maybe some library updates, but I can do those quickly):

• Document that vector3d::rotateXZBy uses right-handed rotation and test for the other 2 similar rotation functions and getHorizontalAngle what they use. (edit: done)
• Having paths to sub-libraries makes no sense. Unless we rewrite the non_system_lib defines, then everything should use paths (this is about Makefiles and the way we switch system/non-system libraries and about recent bugs which were related to that. Have to think about that one some more, because by now I found out some reasons why it's done as it is. Maybe will be pushed past 1.9 release).
• documentation for ECFN_DISABLED says: (disable also writes to depth buffer). I don't think that is true (maybe was once?). (edit: done, was OK)
• matrix4::getRotationDegrees - the version without parameters could try fixing scale with flipped handedness.
  Start by checking if/why rotation around 180° works (instead of ending up as scale -1) (just something looking suspect to me).
  But basically we messed up there - getRotationDegrees and getScale should be back to how they were long time ago in Irrlicht, doing nothing but returning values unmodified. We need a new decomposition function and then see how the rest can be adapted without breaking anything for Irrlicht 1.8
• ITexture::lock() says it returns data with getSize() - check if that is always true or if it returns getOriginalSize when original image is kept around (or on software drivers) (edit: done)
  Also check: \param mipmapLevel NOTE: Currently broken
• New IRenderTarget interface:
  • CNullDriver::setRenderTarget automatically uses ECF_D24S8 for depth-texture. But that's not supported on all platforms.
    In the past Nadro coded getZBufferBits which was used for finding the enum to use. But back then we also could split depth and stencil buffer.
    Still such a function should be used again to avoid using an invalid enum.
    Maybe also should have another name - not returning enum when the name says it returns bits. It's getDepthStencilEnum (note: getZBufferBits is not used at all right now anywhere!)
  • Also - why is splitting depth-buffers and stencil-buffers no longer supported? There are still platforms which don't have combined textures like ECF_D24S8 and do need to split those. Could maybe be handled by splitting getDepthStencil into 2 functions? (I didn't research that further!)
  • IRenderTarget::getTexture should be getTextures
  • IRenderTarget::setTexture should be setTextures (well, now it's been misspelled for so long I hardly dare changing this anymore, so maybe just leaving it as is)
• setRenderTargetEx is documented wrong (or coded wrong - either should go back to previous rendertarget on 0 as documented or change docs)
  https://github.com/minetest/irrlicht/pull/42
• FileSystem::createAndWriteFile said to convert name to lowercase (doesn't it's the bug with filelists): http://irrlicht.sourceforge.net/forum/v ... =4&t=50767
  Same: addFileOpenDialog, ignores case on Windows due to CFileList implementation. http://irrlicht.sourceforge.net/phpBB2/ ... highlight=
  Also patch #294 is about this.
  Maybe using getAbsolutePath in createReadFile also not necessary? Seems to be about same stuff.
• Go over examples (done for first 28)
• Find a good new naming scheme for dll's to have stuff like Debug/Release at least (but maybe more, like x64 and mt)
  While at it - also consider giving code::blocks a 64-bit version (add compile flag -m64)

Note that a bunch of stuff is just - figure out _if_ there is something to do. I constanly get those, either they end up as new tasks or go away ;-) (or even more often they end up in my post 1.9 todo list, not gonna post that now, it's a tiny bit longer...)

[Virion]

I haven't logged in to this forum for more than 5 years now. Just now I decided to check out irrlicht and found this relatively new thread, surprised that you guys are still here. I'm logging in just to reply this thread. I didn't even know CuteAlien is one of the main developers now lol.

Just saying, I can actually help out with something if you guys need. Maybe create some demo with quality assets, or documentation. Just let me know. Cheers.