Using Armory as a library, not as an engine

porky11 · January 24, 2019, 6:31pm

I normally don’t like engines, but Armory looks pretty good, because it’s based on blender, which I already know and like, and supports all programming languages using wasm.

I’m currently using rust as my main language, which is even mentioned in the wasm section, but also may want to switch to different low level programming languages, which can interface with C and compile to llvm (and so also wasm).

The wasm C API looks pretty minimal, though. It seems, when I want to use wasm components, it’s not possible to query state of the objects, at least not in an usable way.

So when wanting to write more complex things in wasm, like a physics engine (or use nphysics), the only way to run the program, I can imagine, is, having a single object, which knows about everything in the scene oneself and just sets the object transforms to new values or creates objects using the js-api.

It’s not possible to use blender animations, when I want to use my own physics engine. It’s not even possible to query the geometry of my objects, so the physics wouldn’t even work well.

Is there a way to program most of the game in a systems programming language like rust, and just use the blender/armory part for the things, I don’t want to write myself?

Or some more practical example: I have written a program to process story events in C.
I want to be able to react to events in the scene, like collisions. When you reach some place, the C program determines, depending on the place, which places are possible destinations, now, and places some objects there to show, something is going on there.

I assume, calling wasm from Haxe may help there, but I’m not sure, how. Is it even possible to call wasm modules from haxe, which also use the wasm C api of armory?

zicklag · January 24, 2019, 7:32pm

About the WASM API being limited, I think it might be possible to get around that and expose the entire Kha, Iron, and Armory APIs to WASM. I don’t really know WASM, but here is the script that loads the WASM traits:

github.com

armory3d/armory/blob/master/Sources/armory/trait/internal/WasmScript.hx

package armory.trait.internal;

#if js

import iron.data.Data;
import iron.data.Wasm;
import iron.system.Input;
import iron.system.Time;

class WasmScript extends iron.Trait {
	var wasm:Wasm;

	var objectMap:Map<Int, iron.object.Object> = new Map();

	public function new(handle:String) {
		super();

		// Armory API exposed to WebAssembly
		// TODO: static
		/*static*/ var imports = {

This file has been truncated. show original

It manually builds out that limited list of functions in the imports and gives it to the WASM module so that it can call what is exposed. Right now that API is manually provided in this script, but it could be possible to automatically generate the imports for the entire Armory API with Haxe macros.

I’ve done something similar before, where you compile Armory, and use a custom Haxe macro to hook into the parsed Haxe classes at compile time and generate your own bindings to the API. It might be a little difficult to support the entire Armory API through a WASM interface; you might run into some issues that I’m unaware of just because of how Haxe is designed, but it might be worth a shot. I don’t have the time to do this right now, but it could be something to consider if anybody else is interested.

porky11 · January 24, 2019, 8:40pm

Good to know.
So the wasm C API is just another haxe script.

This means my idea about just calling wasm from haxe was right, and I don’t even need to combine it with the wasm script type. It’s probably best to expose my own functions, only what I need, instead of just everything.

Didier · January 24, 2019, 11:01pm

Did you try kha, and particularly khamake that allows you to integrate others kha projects ?

MikeRobinson · January 28, 2019, 2:31am

To my way of thinking, “WebAssembly” is a “not-applicable special case” because it is a virtual-machine environment that runs client-side in a browser scenario. (Much like JavaScript … which it is essentially devised to replace.)

zicklag · January 28, 2019, 2:37am

WebAssembly is a valid potential target for Armory because of Krom which is an environment for Javascript that has bindings to Kore, which is the same C++ library powering the Armory C/C++ builds. It is actually nicely performant, but it only runs well on desktop systems because it requires runtime code generation which isn’t available on Consoles/iOS.