Armory needs more users!

[Naxela]

@Antoine_Henry

excuse me if i gave you the idea of being a dissatisfied users, as it was surely not what i intended. I am aware of the tons of work programmers spent to gives the ability to play so easily with those tools and could not thank enough the person behind them.

And i’m sorry you think I was this kind of person. You surely refer to my sentence

" if the engine is a dead end, why do I bother to learn and use it?"

. That was not at all meant as a diss, but a proper reflexion one can have before hoping into something, whatever it is.

And of course, i know who i am, a newcomer, with far less knowledge and experience than you, don’t get me wrong.

So please sorry if you took my comment the wrong way, as it was not at all intended.

I’m not sure, but I think he was probably referring to some of the other more negative commenters in this thread referring to perceived stalled engine development.

[Naxela]

While there are a bunch of good suggestions in this thread, there’s also the general misconception that armorpaint is a totally unrelated endeavour to Armory3D, which isn’t true.

Armorpaint can be considered a production testbed for Armory3D, and it makes good sense for Lubos to work on it, since the interest for it is larger, but it’s also much faster to iterate in a smaller enclosed environment when it comes to new features and stability. There are several areas where this is the case:

• Armorcore/Kromx: Without a solid and stable Krom (Ref. Armorcore) as the underlying runtime you won’t be getting much out of Armory3D anyway. Both Armorcore/Krom, as well as the Kinc framework it’s based on is receiving regular commits from Lubos.

• Raytracing: The problem here is that Armory3D is a cross-platform package, had it just been a Windows engine, the underlying framework would also be there for raytracing, but since DirectX-based raytracing (D3D RTX) isn’t available on Linux and OSX, additional work needs to be put in Vulkan based raytracing (Linux) and Metal based raytracing (OSX), again this is easier to iterate on the smaller Armorpaint environment at first.

• Kha/Kinc: The underlying framework on which Armory3D/Iron is based also regularly receives commits from Lubos. Inside this repository itself, there’s been essential changes that has opened up for beneficial changes, regarding the areas of moving from G4 to G5, WebGPU and moving lower levels of the engine from Kha to C for performance.

In other words, Armory is much more than just a few commits to the Armory repo.

Another thing is the definition of core-developers. While Lubos is still considered the main developer of the engine, there is a bunch of other people who do a great bunch of vital work to both the upper and lower part of the engine, these includes MoritzBrueckner, N8n5h, QuantumCoderQC, knowledgenude and many more: https://github.com/armory3d/armory/graphs/contributors?from=2015-10-25&to=2021-03-24&type=c

---

As for the idea of regular user or even core-dev/contributor meetings, these would be beneficial even if it’s without the presence of Lubos, as it would give insight into what problems, projects and ideas the community has as a whole.

The OSArch group (OSArch Community) that is part of the BlenderBIM addon for Blender holds a monthly meeting every now and then that is then uploaded to Youtube (OSArch Monthly Meetup - YouTube), these provide great insight into the status and upcoming features of the BlenderBIM/FreeCAD/OSArch project - I do think that a similar approach would be resourceful for Armory3D contributors as well as general users, provided someone has time for it.

[JavierHR]

I will only say one thing. Armory does not attract more users because it lacks something very important in a video game engine: STABILITY. This is the most important factor in my opinion to be able to develop serious projects. The day that Armory is a stable engine, video game developers will stop having it as their playground and will take it more seriously