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.

[chronologicaldot]

I'm glad there's still interest in support for the engine. When I posted, however, I felt like the Engine didn't fit my needs. No matter what project I had in mind, Irrlicht seemed to be missing something essential that other engines seemed to have. Of course, I didn't try out all the other engines...

For 3D, the main issue with Irrlicht was that there was no proper support for modern animations. If I could understand the stupid cryptic specks for glTF, I would have probably written an importer for Irrlicht a long time ago. However, I also notice that the graphics systems for newer and newer PCs are moving away from OpenGL and towards Vulkan, not to mention Irrlicht uses OpenGL 2 (as I recall) and the tech is already onto 4. So I feel like it's only a matter of time before Irrlicht no longer runs. But it works for older PCs, if that's what you want to support.

For 2D, Irrlicht works just fine. In fact, you can even use 3D billboards to do 2D games with depth. I've considered this option. However...

Overall, Irrlicht is missing support for game controllers and audio, and it's GUI needs help. I've found other tech, like web-tech, actually has these features now, so it's becoming more feasible to create games with web-tech.
That said, for games requiring lots of nodes, I've considered Godot because it runs native and I can add C++ extensions.

In some ways, for me, it really boils down to the fact that there's alot of stuff I really would rather not do anymore. There's all this great tech out there and people doing some really cool modern stuff in a year or two, but with Irrlicht, it just feels like I have to build everything from spare parts. That's fine if you want complete control over your pipeline. But I feel like I'm getting too old for that.

[n00bc0de]

For 3D, the main issue with Irrlicht was that there was no proper support for modern animations. If I could understand the stupid cryptic specks for glTF, I would have probably written an importer for Irrlicht a long time ago.

I have heard complaints about irrlicht's animation system but I can't really understand what features people are missing. Irrlicht is designed to be easily extendable. You can make a class that inherits from ISceneNode and change how its animated and rendered. I don't know specifically what features you are missing because I have managed to do anything I want with the basic animation features of ISkinnedMesh and IAnimatedSceneNode.

Also, someone has done some work on GLTF. You can find it here: https://github.com/jordan4ibanez/irrlic ... s-animated

However, I also notice that the graphics systems for newer and newer PCs are moving away from OpenGL and towards Vulkan, not to mention Irrlicht uses OpenGL 2 (as I recall) and the tech is already onto 4. So I feel like it's only a matter of time before Irrlicht no longer runs. But it works for older PCs, if that's what you want to support.

OpenGL is old but you don't have to worry about it going anywhere. Vulkan does have the benefit of being lower level but it doesn't mean instant better graphics or better performance. It depends on the developer.

Overall, Irrlicht is missing support for game controllers and audio, and it's GUI needs help. I've found other tech, like web-tech, actually has these features now, so it's becoming more feasible to create games with web-tech.
That said, for games requiring lots of nodes, I've considered Godot because it runs native and I can add C++ extensions.

I personally just use Irrlicht as a graphics engine and use SDL2 for controller and audio support. Just enable to SDL device when compiling Irrlicht.

On the GUI point, there are a lot of options for GUIs with irrlicht. I personally use wxWidgets. There is also ImGUI, CEGUI, and QT.

In some ways, for me, it really boils down to the fact that there's alot of stuff I really would rather not do anymore. There's all this great tech out there and people doing some really cool modern stuff in a year or two, but with Irrlicht, it just feels like I have to build everything from spare parts. That's fine if you want complete control over your pipeline. But I feel like I'm getting too old for that.

Thats understandable. If you don't need full control over your pipeline then Irrlicht probably isn't for you. If you do have a unique pipeline then Irrlicht is a much better choice than a full blown game engine. Another major advantage Irrlicht has is its consistency. Irrlicht code from 20 years ago still works. You can't say that about any game engine.

All of that said, Irrlicht is far from perfect but the only other C++ graphics engine that really competes with it is OGRE. They are both good engines. OGRE has more built-in features out of the box but Irrlicht is way easier to extend which is ultimately why I chose Irrlicht. Maybe you can try OGRE and see if it meets your needs.

[chronologicaldot]

For 3D, the main issue with Irrlicht was that there was no proper support for modern animations. If I could understand the stupid cryptic specks for glTF, I would have probably written an importer for Irrlicht a long time ago.

I have heard complaints about irrlicht's animation system but I can't really understand what features people are missing. Irrlicht is designed to be easily extendable. You can make a class that inherits from ISceneNode and change how its animated and rendered. I don't know specifically what features you are missing because I have managed to do anything I want with the basic animation features of ISkinnedMesh and IAnimatedSceneNode.

Also, someone has done some work on GLTF. You can find it here: https://github.com/jordan4ibanez/irrlic ... s-animated

Interesting. I wasn't aware of that project. How did you manage to find them? (if I may ask)

However, I also notice that the graphics systems for newer and newer PCs are moving away from OpenGL and towards Vulkan, not to mention Irrlicht uses OpenGL 2 (as I recall) and the tech is already onto 4. So I feel like it's only a matter of time before Irrlicht no longer runs. But it works for older PCs, if that's what you want to support.

OpenGL is old but you don't have to worry about it going anywhere. Vulkan does have the benefit of being lower level but it doesn't mean instant better graphics or better performance. It depends on the developer.

Well... considering Apple dumped OpenGL, it's not that OpenGL is forever, but fair point. However, as time progresses, it may be harder to find the docs and tuts needed to learn what's necessary. Everyone else will have moved on. I hate that about most tech communities, which is probably why I like Irrlicht's community so much.

Oh, and I'm not arguing that Vulkan is better. I'd rather work with OpenGL.
What's the status of OpenGL 4 in Irrlicht, though??

Overall, Irrlicht is missing support for game controllers and audio, and it's GUI needs help. I've found other tech, like web-tech, actually has these features now, so it's becoming more feasible to create games with web-tech.
That said, for games requiring lots of nodes, I've considered Godot because it runs native and I can add C++ extensions.

I personally just use Irrlicht as a graphics engine and use SDL2 for controller and audio support. Just enable to SDL device when compiling Irrlicht.

On the GUI point, there are a lot of options for GUIs with irrlicht. I personally use wxWidgets. There is also ImGUI, CEGUI, and QT.

wxWidgets is a wrapper for the "native" GUI system, so I always laugh when I see it.
ImGUI and CEGUI are ugly.
Qt is proprietary.
I complain, but of course, I did figure out how to put Irrlicht in a GTK window. That was cool and probably the best approach for me. But for a game GUI, none of the above is suitable. I did like the structure of the GUI classes in Irrlicht and at least with Irrlicht I could set the skin. (I did make my own GUI skin for Irrlicht, which was cool.) The bummer is that there are a number of GUI elements missing from Irrlicht that I'd have to hard-code, and I find it easier to do in web-tech than C++. Or maybe I'm just tired of reinventing the wheel.

In some ways, for me, it really boils down to the fact that there's alot of stuff I really would rather not do anymore. There's all this great tech out there and people doing some really cool modern stuff in a year or two, but with Irrlicht, it just feels like I have to build everything from spare parts. That's fine if you want complete control over your pipeline. But I feel like I'm getting too old for that.

Thats understandable. If you don't need full control over your pipeline then Irrlicht probably isn't for you. If you do have a unique pipeline then Irrlicht is a much better choice than a full blown game engine. Another major advantage Irrlicht has is its consistency. Irrlicht code from 20 years ago still works. You can't say that about any game engine.

All of that said, Irrlicht is far from perfect but the only other C++ graphics engine that really competes with it is OGRE. They are both good engines. OGRE has more built-in features out of the box but Irrlicht is way easier to extend which is ultimately why I chose Irrlicht. Maybe you can try OGRE and see if it meets your needs.

I did look into OGRE. It doesn't have a native GUI. lol. ImGUI works with it, but I'd still have to find something for production.
Thanks for the recommendation.

Sometimes, you're right, I go back to Irrlicht 'cause it's like gee, it's so easy to just draw what I want on screen with Irrlicht compared to other engines.
Maybe the real problem isn't so much Irrlicht as it is the fact of working ALONE as a dev and feeling like I have to do everything. @CuteAlien - Sound like a familiar sentiment?

[CuteAlien]

Animation system is pretty basic and badly maintained. I learned by now how it works, but still haven't gotten to fixing the animation blending stuff.
And that blending is really only doing the minimum. Other stuff lacking is for example access to the non-animated base mesh or any kind of key-caching to avoid the amount of calculations it does. So I understand when people are missing things. It's enough and simple to use for some games, but for others you'll have to work around it.

UI needs definitely a more modern flat skin. I started looking into that a bit last year, but for now it's pretty far down on my todo list. Thought in general I'm not too unhappy with it (I'm an old guy and really like those 90's UI's where you actually could see which things are clickable).

The drivers side is mainly having the trouble that the material system in Irrlicht was build around the fixed-function pipeline. And that shows a lot. Also access to the drivers is hidden too much - so sometimes hard to advance things for your application without modifying Irrlicht itself (or accessing internal interfaces...). And that is the problem with modern systems like newer OpenGL, D3D or Vulkan - they are all 100% shader based. So one either lets users do a lot more work (everyone write your own materials), write lots of shaders for Irrlicht (same materials for each system supported )- or we need to write a wrapper around shader systems (aka our own shading language). At some point we have to take that step, but I think this is kinda a new engine then (like Nabla).

And yeah, doing everything is annoying - just now I had to cook and I still have to do the dishes :-( Oh wait... you were talking about coding... well, I'd do more if I were less tired maybe. Which got a lot worse since the US elections for some reason, the daily crazy news since then is really not good for my mind! Anyway, right now I'm taking off some time (no real holiday, just not working) and by next week I hope I'll be up for some more Irrlicht coding.

[n00bc0de]

I don't have anything to add to what CuteAlien said. I would like to address a few things you mentioned.

You asked how I found that GLTF repo. If you just type Irrlicht in the search bar on github you will find a ton of open source projects you can go through. I am a firm believer in not repeating work someone else has already done.

Another thing I would like to address is my comments on UI libraries. I was mainly referring to libraries to use to build tools with. For example, a level editor. I built 2 editors for my pipeline using Irrlicht and wxWidgets.

The first editor is called Nirvana2D, and its a 2D tilemap and sprite editor:


The second is Serenity3D, which is my 3D level editor (NOTE: The toilet icons are for adding animated scene nodes and octree scene nodes. I will change them before I do an official public release.):


They are both open source and available on my github page but I wouldn't recommend trying to learn from my code. Its not pretty. wxWidgets and irrlicht are a good fit for building tools though. For in-game gui, I always build that myself. It always made more sense for me personally to just cater my UI to the game I was building.

My github page: https://github.com/n00b87


Lastly, on the opengl on Apple point. You are right but to be fair, Apple doesn't officially support Vulkan either. It has support through MoltenVK but that is an opensource project not affiliated with apple.



@CuteAlien I hope you get a chance to rest up. I know a lot of crazy stuff is going on so its always good to take a breather occasionally.

[chronologicaldot]

@n00bc0de
Nice projects you got there, at least from the screenshots.

I guess I shouldn't be too concerned with Apple since they do their own thing anyways.
I've read on the Khronos forums that it's not likely OpenGL is going to completely disappear. It's more like Vulkan is there for those who need low-level access (like raytracers). Personally, I don't like the extra work necessary for Vulkan, so if tech is going to phase out, it's nice to be already acquainted with an engine that does it for you.

@cuteAlien
I do like the simplicity of Irrlicht. That's one of it's main appeals (over beasts like OGRE, pun intended). I guess my biggest gripe has always been trying to get 3D models animated. But now that there's stuff about tinygltf floating around the forums, I should look into that, and maybe I can integrate the MineTest stuff into an external mesh loader and put it in my IrrExtensions.

[Noiecity]

I don't have anything to add to what CuteAlien said. I would like to address a few things you mentioned.

You asked how I found that GLTF repo. If you just type Irrlicht in the search bar on github you will find a ton of open source projects you can go through. I am a firm believer in not repeating work someone else has already done.

Another thing I would like to address is my comments on UI libraries. I was mainly referring to libraries to use to build tools with. For example, a level editor. I built 2 editors for my pipeline using Irrlicht and wxWidgets.

The first editor is called Nirvana2D, and its a 2D tilemap and sprite editor:


The second is Serenity3D, which is my 3D level editor (NOTE: The toilet icons are for adding animated scene nodes and octree scene nodes. I will change them before I do an official public release.):


They are both open source and available on my github page but I wouldn't recommend trying to learn from my code. Its not pretty. wxWidgets and irrlicht are a good fit for building tools though. For in-game gui, I always build that myself. It always made more sense for me personally to just cater my UI to the game I was building.

My github page: https://github.com/n00b87


Lastly, on the opengl on Apple point. You are right but to be fair, Apple doesn't officially support Vulkan either. It has support through MoltenVK but that is an opensource project not affiliated with apple.



@CuteAlien I hope you get a chance to rest up. I know a lot of crazy stuff is going on so its always good to take a breather occasionally.

Wow, nirvana 2d and serenity 3d look very good editors, do you have the compiled version for windows of serenity 3d? i would really like to use it but i don't know how to compile it.
I would also like to use nirvana 2d if it is based on irrlicht, it would help me something that makes it easier for me to do that... for an isometric game using sprites.