Irrlicht needs more help

[mant]

It has been a long time since I learned Irrlicht for the first time, several years since I was at secondary school and now I'm having 2 years left to the university graduation.
I really like it and use it in my first game production (http://irrlicht.sourceforge.net/forum/v ... =6&t=52165).

I want to have some words to the developers and community and I will keep believing in Irrlicht and helping as much as I can.
Besides clean API design and easy-to-use philosophy that bring new users to it, there are also problems that make Irrlicht not suitable for long term and advanced use.

These are some of my suggestions:
1. Forum is running with old software and hard to follow when digest email/notification is not available as a function, please consider upgrading
2. Development is not really open, you have to dig deep to find out what is happening there

Details:
It's pretty obvious that we should keep the forum not fragmented and easy to communicate.
For example myself, even I like Irrlicht much but it's hard to stay on the forum, I often ask then leave.
After thinking really seriously that I should post something because I could help a little, these kind of posts pop up in my head.
So you get the idea, the forum is not engaging enough for users to participate in.
Then I looked for some options that I could turn on to watch for new posts, but didn't find it.
Please upgrade or install plugins for phpBB, migrating to better forum software is also an option.

Let me explain what I mean when saying the development is not open:
I know many folks still like old-school methods, but remember that new generation of coders won't tickle IRC, svn, even sourceforge (except for easy one-click downloads ) to do open-source stuffs.
I would be great if Irrlicht was moving to git. I guess that admins and mods are aware of that but I don't understand why we are not moving to major platforms to find more users and development opportunity.
It's logical to say that SVN has some advantages over Git, OK. But I really think that it won't harm much if we are on a base of many users already (github/gitlab/bitbucket).
Moving to git is not what I really want to stress here, I'm only giving examples about one of the ways that we could do to make it more open.
SVN ans SF are fine and I'm about to learn them with the hope of better understanding about Irrlicht's development, but I'm not sure about the majority of people.

Many people are modifying Irrlicht for their own advanced requirements but do they contribute back? My guess is that they do it in their own git repository so sending patches or SVN commits is something regarded as time consuming for them, sure, their work is much more important and it's not wrong.

More:
I also want to suggest that we build an active instant messages channel using Slack or Discord, IRC seems not helping new users like me at first, we don't even get new users to ask on IRC because they seem don't care what the heck IRC is. Development discussion is also possible to happen on IM.
Again, not a strong belief but it would better if we let people know that we want chat and we want good chat, maybe people could get excited and help you.

So my whole point in short is I think the community is very fragmented, everyone here is busy doing their own parts: showing the own work, seeking for help, being flooded with questions (like CuteAlien - He spends time helping much so who is gonna take care other aspects efficiently?)

"Irrlicht is dead" - said by someone to me, I still don't believe it so this is one of my trials to prove the opposite.
Let the people know how you think about Irrlicht's future here and discuss how we could make it happen.
Thanks for reading.
Manh.

[CuteAlien]

About forum notifications - the reason for that isn't the software (it worked in the past) but that sourceforge disabled sending mails out from their servers as that was abused too much. Like always on the net - spammers killing nice free services :-(

We will switch to git after Irrlicht 1.9 release. I had to learn to use it somewhat first and didn't want to do that with an open project. Note that this will make forum situation worse as github has no forum support whatsoever. So project will be split between sf and github or something like that ... really haven't a good solution for this yet.

I don't know slack but run Discord sometimes when I'm on Windows (haven't manage yet to get it work on my Debian system). It's cool - but I feel it's more targeted at gamers while most open source projects are on IRC.

And Irrlicht is immortal, no worries there ;-)

[mant]

Slack is really good for communication, it is made for small team and enterprise chat.
Here is a screenshot of slack with Cpplang (a C++ community blessed by isocpp.org).

(Open in new window to see in full size)


Many open-source projects are using slack or gitter (github chat).
Discord is made for gamers but others are using it too, including gamedev.net and tigsource.
I myself like slack more. We also have a gamedev community on slack and I integrate gitlab to a channel.
Then every time we have a commit, issue, ... a message is sent to slack.
Discord is not simple and looks bloated in my opinion.

To seriously develop an active chat community, please assign people who are really responsible for advertising and managing the channel often.

About forum, please consider migrating to another php software that has notifications in website.
phpbb also has a plugin for that: https://www.phpbb.com/community/viewtopic.php?t=2370946

Or better, consider migrate forum to MyBB since it has better UI and support of all kinds.
Including the notification system: https://github.com/MyBBStuff/MyAlerts

To convert existing forum to MyBB: https://mybb.com/download/merge-system/

About github and SF, I think we could use SF for web hosting only: main website and forums.
You can put downloads on github. Github already has issue system and we can find ways to export current tickets to it.
For example: https://github.com/cmungall/gosf2github

[mant]

What I could help:
- Set up slack with automatic invitation (also git integration):
Normally you'll have to add people manually by typing their email address.
But I can do something like this for Irrlicht's slack (heroku's free hosting): http://gdspot.herokuapp.com/
So people can join on their own.
- Set up a forum on a virtual machine to test migration to MyBB with notification system if forum snapshot was provided.

[Brainsaw]

My 2 cents: Slack would be cool, we use it in the company (non-gaming) I get my money from (distributed all over the world so it's a good communication channel imho. We also had to migrate to GIT when our company was baught by a bigger (global) company but I'm just an end-user and weren't involved in the migration. In the beginning it was hard for us but today we like it much (I guess most of my colleauges do ), but my private project is still hosted at sourceforge as I'm doing the work alone and in this case I don't see the advantages of GIT. For a project with multiple suppliers it would be a good choice though (imho)

[hendu]

The way you feel about IRC, it's the same the older gen feels about Slack and Discord, ie "Hell No".

[CuteAlien]

@mant: Notifications are not a software problem - the current forum can already do that. It's the servers which block outgoing stuff. Changing software won't help there. We also had do disable email verification for the same reason for example.

[chronologicaldot]

Tools are tools. I use Gitless (for simplicity) but sometimes have to resort back to directly using Git for things Gitless lacks. For SVN, I used Tortoise for awhile but went to just plain old command line.
The main benefit that "Git" has isn't really Git at all - it's everything around it. Github is nice for viewing all of the code, seeing changes, etc, but SF might not be so bad either if we placed in a prominent position the SVN command to download the latest version:

Code: Select all

 
svn checkout svn://svn.code.sf.net/p/irrlicht/code/trunk irrlicht-trunk
 

Perhaps contributing to Irrlicht would be easier if it were on Github. Forking would be at the push of a button. *shrug* I'm not for or against the move.
Then again, if someone wanted to use Irrlicht from Git now, it appears someone was already automatically copying everything (at least up until last month):
https://github.com/zaki/irrlicht
(though admittedly, there is no way to individually contribute back to this copy)

If the move did happen, what would happen to all the stuff here?

[CuteAlien]

chronologicaldot: Forum will live on in some way. Way too much information to drop that (I use it all the time to find stuff myself...).

[kklouzal]

If you guys didn't know, GitHub makes it extremely simple to migrate from SVN to GIT
https://github.com/new/import
There are also scripts to import issues.

I can say I've refrained from even attempting to contribute to the project simply because It's not up on GitHub. I've been itching to convert Irrlicht to STL for a very long time.

[mant]

@mant: Notifications are not a software problem - the current forum can already do that. It's the servers which block outgoing stuff. Changing software won't help there. We also had do disable email verification for the same reason for example.

You're still talking about email, man? I was giving solutions for the notifications in the forum interface.

The way you feel about IRC, it's the same the older gen feels about Slack and Discord, ie "Hell No".

Slack also has IRC gateway for guys that still like it.

[mant]

My 2 cents: Slack would be cool, we use it in the company (non-gaming) I get my money from (distributed all over the world so it's a good communication channel imho. We also had to migrate to GIT when our company was baught by a bigger (global) company but I'm just an end-user and weren't involved in the migration. In the beginning it was hard for us but today we like it much (I guess most of my colleauges do ), but my private project is still hosted at sourceforge as I'm doing the work alone and in this case I don't see the advantages of GIT. For a project with multiple suppliers it would be a good choice though (imho)

My private projects are on gitlab, they has free plan for 10gb/each git repo and 2000 minutes of CI a month.
Storing large files is also easy with Git LFS, I store game data (mesh/textures, ... and any binary file on it).
I host multiple websites on gitlab too, as long as they're static websites you can have unlimited sites with custom domain.
(Also good for blogging since you can add disqus comments to a static site).
These are some advantages for personal use in my opinion.

[CuteAlien]

Basic problem is that Irrlicht does not need more feature developers but more maintainers. Right now far too much of my time is spend hunting stuff that broke at some point and figuring out what the coders (which often are gone) have thought about it when coding or changing things. Around 2/3 of my open todo's for Irrlicht 1.9 are maintenance problems and those are the real problems which take lots of time. I don't worry much about new features, adding those is fun and I'll enjoy getting back to that once I fixed all the troubles the last set of features has produced (some of my own actually, but more not). But as I doubt switching to git first will get me even a single patch for the real problems I'm struggling with in Irrlicht right now that switch will be after 1.9 release, not before. I'm even somewhat glad that other programmers are pausing with features currently as it's the only chance for me to catch up a little bit. Stuff like switching to STL - that's fun and I'll enjoy doing that after 1.9. Rewriting a string split for the 3rd time... try to find motivation for that (some todo's will just make you close your IDE). Or figuring out the interplay of rendertargetsize, device-size, viewport size and the OnResize function in videodrivers in combination with GUI. Stuff which means you have to reboot several times while developing just to see what it does on each OS and then try to find out why it goes so horribly wrong on Android. And do that all when you wrote none of the code involved and you haven't even worked on OS level much on Android.

I get that people want to help stuff getting forward with Irrlicht - but boring maintenance _is_ the stuff blocking Irrlicht because it got neglected too much in the past because everyone just put in more features and left bug-fixing for the next guys. Thought there is also another option - ignore all maintenance and kick out everything you don't need yourself - I kinda like what devsh does there - reducing Irrlicht to OpenGL and kick out everything that has collected dust for years. I often consider doing that as well, but basically that means I would no longer work on Irrlicht, but would do my own spin-off engine.


edit: Just to give you an idea how the real problems look like. This is a list of things which I did _not_ plan for Irrlicht 1.9, but did come up within this year while I tried to find time to work on the Irrlicht 1.9 todo's (there have been a lot more certainly, this are just the ones which are still open and not fixed already). So this is basically the list of things where I have not even decided yet in some cases if it's a problem for Irrlicht 1.9 or not. The real 1.9 tasks are a similar list I made a year ago. Note also that at least 6-7 of those are caused by recent featues (which were not yet in Irrlicht 1.8).

Bug (#440) with GL materials using second texture when drawn twice.
https://sourceforge.net/p/irrlicht/bugs/440/

Check android rotation: http://irrlicht.sourceforge.net/forum/v ... =1&t=52095
Irrlicht simply ignores rotation - which means coordinates are wrong, drawing is wrong, etc.
Actually - Irrlicht never translates input-coordinates on Android - when using other resolutions it's very noticable.
And it probably should have some parameter for resizing (if it's possible to resize a context at all - likely not).
Resolution given in createDevice < real window size = viewport always left-bottom corner.
When createDevice > real window... not sure. for some reason also drawing below expected top then.
(my moto-g should have 1280×720, but test if that's true)

Go over examples (done for first 10). Like example 13 using "test" as variable name and creating textures outside the scope they have to be and documentation mixing rendertexture and rendertarget.

Maybe light problem: http://irrlicht.sourceforge.net/forum/v ... =1&t=51712
Explanation is likely wrong documentation (radius doesn't mean light stops but stops beeing full brightness).
See http://www.glprogramming.com/red/chapter05.html
(example to test in ~/official_irrlicht/linux/IrrlichtStuff/camacho/IrrOde)
Check if a spot-light (with 180.0 degree angles) can be used for a hard cut-off at a certain radius.

Bug in toolbar placement when a modal dialog is open. See code gui_toolbar.cpp in irr-playground-micha repo.
bug-example from Sérgio Augusto Vianna, bug-report from Stephen Lynx

Also while working on modal: Make it more clear in documentation that the modalscreen should be the parent of your modal window (so modalwindow->addChild(yourmodaldialog))

Rewrite string::split once more: http://irrlicht.sourceforge.net/forum/v ... 34#p299634

billboard drawing, sorting transparent stuff: http://irrlicht.sourceforge.net/forum/v ... =1&t=51598
See also very old topic about this: http://irrlicht.sourceforge.net/forum// ... hp?t=33410
And bugreport: https://sourceforge.net/p/irrlicht/bugs/262/
And feature request (with link to code): https://sourceforge.net/p/irrlicht/feat ... uests/128/

Quaternions:
Maybe check (quaternion rotation problem, but... bad testcase): http://irrlicht.sourceforge.net/forum/v ... =4&t=51520
Update for that one - it has a fix now for Irrlicht!

Quaternion slerp and lerp should normalize their results. lerp is never used inside Irrlicht, but why are there no errors with slerp in Irrlicht? Or did they simply not get reported yet?

CAnimatedMeshHalfLife using it's own quaterion slerp function - should use irrlicht core classes (but whole CAnimatedMeshHalfLife looks to me like a copyright violation... I don't want to touch that one)

quaternion (another float trouble *sigh*): http://irrlicht.sourceforge.net/forum/v ... &start=120

quaternion to euler bug? (Hybrid mentioned gimbal lock problem in toEuler): http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=43725

Reflection opengl linux broken (not yet tested on Windows) since r4989. Switch to reflection in material viewer messes up the gui. (log just says: Fixed issue related to rev4986.).
(probably fixed now, just not yet read&tested fix)

Revision 5279 (replacing mipmap parameter in ITexture by 'layer' - which sounds strange... why not a new parameter?) broke many Burnings tests failing, for example terrainSceneNode (only 2 tests - not mentioning driver?) and lightMaps
(likely fixed now, just not yet read through &tested fix)

Can we rename draw2DImage to get rid of: warning: 'irr::video::COGLES2Driver::draw2DImage' hides overloaded virtual function. Same in COpenGLDriver (COpenGLDriver.h:147)
It's only used in COpenGLCoreTexture::lock. But I'm not quite certain yet about the cubemap/layer stuff there. Slightly irritating to have "layer" suddenly mean something new than in the past.

32-bit obj loader patch: http://irrlicht.sourceforge.net/forum/v ... =9&t=51441
(also has STL patch, LWO also could need it - see NASA-3D-Resources\3D Models\Aeronomy of Ice in the Mesosphere)
But needs change of meshbuffers first so they can tell their own type. Otherwise it breaks current hacks where people cast to meshbuffer implementations knowing which type is used (by looking it up in code).

Font-test ttf.cpp makes font more invisible with each new character typed when ETCF_ALLOW_MEMORY_COPY is not set.
E:\projects\yoran\i3\freetype\objs\vs2013\x64
See also other test-case for (probably) same bug: http://irrlicht.sourceforge.net/forum/v ... 22#p300322
My guess: Alpha handled wrong. It looks a little bit like it only gets on/off for alpha and no values in between. (likely we get colors where alpha is applied already + alpha so we now have alpha twice)
Check code in COpenGLCoreTexture.h lock()

Should probably add those flags to examples in c::b for Linux (but do after merging ogl branch, we maybe disable ES1 anyway. Also GL might be used already): GL EGL GLESv1_CM GLESv2
Or maybe we need different targets for that (as most people won't need ES by default).

Demo D3d9 shadows broken in r4794. Shadows should have better tests.

[devsh]

The most frustrating part is that most of your maintenance bugs are the result having waaaaay too many permutations of things which should be programmable, which in turn is the result of keeping D3D and non-core-profile OpenGL drivers.

An example of feature bloat (or maybe too tight integration) are:
1) specifying explicit meshbuffer formats (IrrBaW has full flexibility over everything in a mesh format)
2) abstracting ITexture over IImage and including blitting/copying methods in IImage which creates problems when one wants to add any texture which is not a 2D texture, add explicit mipmap loading support which has been forgotten about, or more texture pixel formats... because theoretically you'd have to add pixel conversion and blitting functions for all pair-wise format permutations.
3) having any explicit materials other than a set of 2 or 3 debug materials such as solid-no-light and transparent-no-light, and ergo having some prescribed light-system.
... the list goes on

All things like that should be in a separate module (or examples) which can be discarded at will.
Best examples of stuff that is not really Rendering related and should be delegated to separate(but maintained) modules:
A) The residual physics, Raycasting and selectors
B) GUI (its really slow, no support for batching or even drawing in one pass using sorting), plus lots of people use CEGUI
C) Asset Loading (we should only support a binary irrlicht format which should correspond well to the meshbuffer format interface and straight raw texture data) plus most people use Assimp and DevIL
D) XML stuff (the algorithms used for matching and finding tokens are naive simplest implementations)
E) FileSystem (should be able to create more instances of IFileSystem for multithreaded stuff)
F) Input (joysticks etc.)

3.3+ Core profile makes a port to OpenGL ES 3.0 (ubiquitous on still supported Android devices) a breeze.

There's also too much abstraction, like packing blend equations and factors into bitfields and neglecting the already ubiquitous separate blend capability.

On top of that you're wasting man-hours supporting and polishing old, deprecated ways of rendering... setting individual constants in shaders instead of constant buffers (D3D10+) or uniform buffer objects (OpenGL) being just one example, and that eats 40% of our CPU time in the render thread in Build a World.
I mean great, you've fixed a bug or polished an interface, but no one should use it anymore!

Reflection opengl linux broken (not yet tested on Windows) since r4989. Switch to reflection in material viewer messes up the gui. (log just says: Fixed issue related to rev4986.).
(probably fixed now, just not yet read&tested fix)

Is an example of what dropping the fixed function pipeline would fix.

COpenGLCoreTexture::lock

No texture class in any driver should have this method, it's a D3D9 antique.

Regarding Euler Angles and Quaternions, we should ditch XYZ rotation convention, and use Quaternions to specify rotations as every legitimate 3D engine does.

The engine would move forward much more productively if we just broke the API and went straight to Irr 2.0

In conclusion no currently manufacturer supported GPU is still D3D10, OpenGL 3.3 non core or OpenGL ES 2.0, so all of that legacy functionality should go.

P.S. 'Resizing a context' would be a function of the windowing extension to OpenGL (ES) not openGL itself, so GLX, WGL, Cocoa and whatever android uses.

[CuteAlien]

devsh: I wouldn't want to switch to using quaternion class. It was written by someone who didn't care much about rest of Irrlicht (this is how we go the mixup of right-handed/left-handed in the past, the person who implemented it didn't even check what the rest of Irrlicht used, which had causes again problems when it finally got fixed which is part of the troubles mentioned above). And it does not normalize slerp results and I still have noe clue why this even works (it probably doesn't, I'm pretty certain there are bugs hidden there). And lastly - we have likely no-one who is really good with quaternions - eulers are easy to understand and work with so at least we can fix any kind of problems that arise there.

And yes, lots of bugs because we try to keep the library working. That's kinda the defintion of a library - an API you can continue to use without having to rewrite your applications all the time. One doesn't need a 3d library and can simply write games for some OpenGL version directly. Format loaders, platform independence, support for older platforms, etc ... is certainly stuff then you lose and have to figure out all on your own.

A) Irrlicht offers some minimal functions there which every 3D engine should offer (and every I worked with so far did).
B) I use Irrlicht GUI a lot and it's really useful. I tried CEGUI once but didn't like it - but each to his own.
C) Maybe. But I'm not adding even _more_ rewrite tasks for Irrlicht 1.9. And it would be ok if not each loader would have been written on it's own _and_ if test-models would have been added to Irrlicht. And maybe some documentation. And no copyright violations. So yeah, not sure what to think about that one.
D) I don't care too much really, as long as we have mesh-loaders it's obviously still very useful.
E) Mostly works and very useful in lots of projects, can't kick that one out.
F) What about it? (It is somewhat a problem when it comes to Android input, otherwise little trouble there).
Most points not really related to my open problems, thought I guess fine to put them up for discussion.

Not sure what you mean by the way when you talk about abstracting ITexture over IImage (what kind of c++ keywoard is abstracting?). Those are independent classes (IImage is about bitmap manipulations, ITexture is about abstracting hardware textures). You can create one from the other but that's about it.

Texture lock() kinda is rewritten to not use lock() anymore (working with RTT's now). But that *is* what is causing the troubles - as it now no longer works correct!