My somewhat broad response to some thoughts brought up in Armory ignoring the Pose Mode?:
I just wanted to bring up that performance of Haxe is going to depend on your target. I heard that Krom is actually benchmarked by @lubos to be faster than the C++ target for Armory. When you target Krom, everything is compiled to Javascript other than Kore ( which is the C/C++ Kha implementation ), so even the Bullet physics engine that was originally C++ is actually running in the Javascript VM.
Writing things in C++ also makes it harder to work with. Part of the reason Armory is such a joy to use, for me, is because of the very nice to read and write Haxe that it is written in. The fact that Haxe compiles in seconds is also a huge productivity boost.
I wouldn’t call writing things in Haxe a workaround. Most of the logic for the engine is in Haxe and I don’t think that there is anything wrong with that. If we get benchmarks made and it turns out that we really need the extra performance and that the Haxe code is too slow, then we should look into doing something about it.
On the subject of the performance of Logic Nodes: Logic nodes compile straight to Haxe so, for the most part, they should be just about as performant as you writing the code yourself. Obviously, the code generated by the logic nodes might be a little less optimized than if you did it manually, but not by much. If you had an extremely complicated logic tree, then the performance toll might become an obstacle, but that just means that you need to consolidate some of those nodes into a more specific node, so that you can optimize the Haxe code that makes up that node.
I don’t think that it is a bad thing for us to start working on things like this. Lubos has been coding this engine for years by himself and now people are starting to get more interested in it as it grows. I think that the community can really help Armory and come up with good ideas as well. Maybe it needs to be written in C++ and maybe it doesn’t, but I think that we all want to do what is best to make Armory awesome. If it is a good solution, it will get merged in and become a part of Armory, if it isn’t Lubose should have the sense to leave it out.
I plan on trying to make a lot of contributions to Armory moving forward and I think that will be a good thing for the project. I think others are getting more interested in finding what they can contribute and I think that is great. We need to collaborate and figure out how to do things, but I think that we can do that and start to work together as a community.
I don’t think that we should take the approach to assume that we will only be making small games in Armory. Call me crazy, but I actually plan on making a sizable commercial game with Armory. I know that the engine is not ready yet, but that is why I want to contribute. I really do think that it could beat Unity and Unreal in the future if enough work and passion is put into it.
Obviously if we have to go way out of our way to make Armory work for open world, then we might need to spend our time on something else. There is always going to be a balance that we have to make, but I don’t think that we should ever just consign Armory to a small game dev’s engine. That would be to limit what it could become if we put the passion into it.