I got a question! I am a very big beginner to the game dev universe and ive got very little experience with armory… but i have a question: can armory be used to make a racing car game:
As in:
Is it capable of car physics (basic physics)
does it have good enough AI capabilities
is it optimised enough for the fast loading of track objects (ie some debris, the road, buildings, trees)
and less important:
can it simulate distruction of cars (something like real time soft body)
can it do post FX like motion blur, DOF, aliasing and other stuff
Asking if i can stick with armory or do i have to switch to a different engine.
If its semi-capable of it i dont care ill stick with armory bc i really like it.
In regards to physics, because Armory uses Bullet, it should be able to handle both basic car physics and destructibility, but you might have to write your own logic for complex mesh destruction ( here is an example of convex mesh break algorithm of some sort ).
Armory is missing some Bullet bindings that it will need for different applications, but I’ve got a work-in-progress effort to automate the physics bindings; I just have yet to find the time to finish it. You can also add them manually without much work.
As far as AI capabilities, Armory doesn’t really have anything out of the box. You’ll have to implement that yourself, or find a Haxe library that somebody else has made. The good thing is that you are completely free to develop it yourself and there isn’t any lock-in to a certain way of doing it ( although you’re probably really going to want it to be written in Haxe to save you the work of binding it with C/C++/JS ).
I don’t know that there has been a whole ton of testing to benchmark how well Armory handles that kind of stuff, but it does have scene streaming to load objects as they are needed and it has LOD support, so the foundation is there, and you could add your own logic to spawn the objects into the scene however you want.
Armory seems particularly well suited for that kind of thing as it has a lot of post-processing options out of the box ( AA, AO, GI, SSR, Motion Blur, HDR, etc. ) and has ways for plugging in your own custom ones. You should be able to do whatever you need there.
The good thing about the physics bindings is that it is just a matter time before they are fully complete so it isn’t going to be a long-term concern. Its just a matter of adding them as they are needed.
Also, I think it helps to take a peek at the Haxe programming language which lurks just beneath the covers of this whole thing. On the one hand, Armory3D is well-integrated with Blender, has cozy things like Logic Nodes and so on – but beneath all that beats the heart of a true cross-platform dragon.
(This is a fundamental tool that I now use for a great many projects, not just 3D graphics …)
The Haxe language has a haxelib package manager, and there’s a very large set of material there, all free for you to use. (Armory, Iron, and Kha are all “haxelib packages” …) Therefore, “look around” at your options in this regard as you begin to put together the design for your game.
And, if you come up with something way-cool on your own during the course of some project, “give back.” Your five minutes of fame awaits you.
Just in some addition on top of @zicklag’s topic and my experience on vehicle physics in Armory.
Armory uses Bullet physics. It does support an out of box vehicle behaviors. However, for racing game that demands cars to drive at high speed, additional tweaks and setups maybe need to done to stabilize the vehicle, otherwise strange behaviors (like car flies off to air in strange rotation ways). It was not armory specific, but just due to how Bullet physics work. But maybe that is the desired behavior for a game too.
Other as mention in previous post, some very detail function may not be bind yet from bullet physics (such as very specific detail rotation and contact object), though there are way to bind it, or at least workaround through other ways. zicklag’s PR will definitely make things much easier used to do these additional bindings for bullet and take trial/error approaches.
Regarding the loading of tracks/other objects. My experience with it is Armory can load quite many objects in scene with decent speed if they are just graphics (no physics) and it seem to able to do backface culling well to save resources. The problem will be on physics. The moment you add a lot of of objects with complex mesh (especially psychic object generated from 3d object mesh), the performance will really slow down (and seem physics will always be there, one way maybe implemented own way to turn off on very far distances so it saves up resources). My resolution was actually create another simpler invisible mesh beside the graphic mesh, so the physics is there to some degree with decent graphics (like road wall)
There is also a small doc on notes I putted together base on my experience with vehicle setup in Armory (please feel free to correct if there are any mistakes)
A demo of a vehicle game (disclaimer, Armory should able to do much better in graphics, it was my model skills that limit it :))
Also carefully consider the frequency with which you invoke the physics engine. For instance, you don’t need to invoke it “every frame.” The engine needs to be informed of the passage of time, but corrections to object movement only need be performed a few times each second.
I always tell people – “be sure to buy some of your testing devices at supermarket checkout lines.”
