Arsenal: The Vision for a Full Amethyst Blender Integration

(Zicklag) #1

Hello everybody!

Me and my team at Katharos Technology are are starting a project to provide Amethyst with a full Blender integration, along the lines another game engine, Armory3D. We’re calling it Arsenal.

Me and my team have been planning on using Armory3D for our games, but after almost a year of being in the community and contributing to the engine, some concerns were brought up about the ability of Armory to scale to larger games because of its single-threaded core; something that is essentially irremediable without a complete rewrite of the core.

My team has big ambitions for our games and having limitations on the size or kind of game that we can make with our engine is not something that we can be satisfied with. After getting deep into Rust programming in the last month, we are convinced that Rust is the best language for writing a game engine and that led us to Amethyst.

Amethyst is very much in line with the vision that we have for a game engine. Written in Rust, highly parallel, built on great existing tools where applicable and building what doesn’t exist, all while trying to beat the big names in game engines such as Unreal and Unity.

The more I look into the things that will be necessary to create the engine that we are imagining for our games, the more Amethyst seems to be working towards similar goals. We need to be able to target consoles and web, support scripting languages, and provide a visual scripting solution; all things that Amethyst is already seeking out.

The biggest missing component of Amethyst, for us, is our favorite thing about Armory3D: the full Blender integration. To be able to build a scene in Blender, click a button, and see it instantly exported and ran as a game is an amazing experience. You can completely skip the potential nightmare of asset import-export. You also get to steal Blender’s amazing user interface and avoid having to build a competent editor. By using Blender you get a built-in modeler, rigger, sculpter, and animator.

Our goal is to provide an experience that is just as amazing as Armory3D’s for Amethyst. We want to make game building as easy and accessible to anybody as possible while not placing any limits on where you can take your game. We are planning on building Arsenal and contributing to Amethyst to make it happen.

There are a couple of things in Amethyst that are WIP that we will need for Arsenal. I may want to help with them if there is room for contribution: scripting support, and OpenGL support.


In order to allow making games easily without having to re-compile Amethyst for every blend file that you open and try to run, we are going to need scripting support. I’ve read over the RFC and I think that it sounds like a good plan. If we can pull off all of the benefits of the plan outlined in the RFC I think it will be pretty amazing.

I couldn’t find a tracking issue for the RFC, which, if I understand the process, should have been created after the RFC’s PR was merged. I wanted to know if there was anything that was tracking that progress. I’d seen some threads on this forum, but nothing official.

Either way, I would like to know if there is any way that I might be able to help with that. I’m fairly good with Rust, but I wouldn’t have a great understanding of the Lua VM or how to integrate that. I might be able to help with the Rust driver, which would be sufficient for me to start using ( I don’t need Lua immediately ). I’m also fine just collaborating on design. Me and my team are good at solving technical problems.

OpenGL Support

A big deal for my team is being able to support hardware that is not necessarily extremely modern. We’re not wanting Amethyst to support ancient computers, especially where it would hurt the engine for more modern machines, but supporting OpenGL is important to us because it can run on pretty much anything and we want our games to be able to support smaller computers with low graphics and larger computers with great graphics.

I don’t really have much grasp on what the workings of any graphics API are, but I learn quickly if I’m given documentation or other learning material.

Also, we’ve still got to write the Arsenal Blender plugin, so we’ve got other stuff to work on if somebody is already working on those features and it would be more efficient to wait instead of trying to contribute.

Anyway, we’re really excited to start working with Amethyst and starting the new Arsenal project. We are writing documentation as we go and putting it here. You can find the source code on GitHub here. We have just started development so thing are completely experimental and nothing does anything yet, but all of our progress will be put on GitHub and in the docs as we go. The current plan is to dual license the project under MIT and Apache 2.0.

We’re open to any feedback you might have and are looking forward to collaborating with the Amethyst community!

Welcome, say hello!
(Erlend Sogge Heggen) #2

I believe we’ll get OpenGL pretty much for free once gfx-rs releases it’s next version with support for glow.

1 Like
(Thomas Schaller) #3

Hello @zicklag!

I’m happy to hear you see Amethyst fit for your project!

That sounds pretty interesting! Do you have any plan on how that will work? Can you just write a Blender plugin which exports the scene and runs the game, which in turn loads the scene?

Ah, yes, scripting certainly sounds useful here, although you might also be able to just reference your .blend files from a RON config as a stopgap solution.

We should probably create such a tracking issue, yes. I’d recommend talking to @Moxinilian about that, he leads the whole scripting efforts.

Ah, I see. As @erlend_sh mentioned already, OpenGL support shouldn’t be hard to get into gfx (I believe it already is implemented on master), however, I don’t know if any additional efforts are necessary for our rendering engine rendy to pick that up. I’m sure @omni-viral can tell us about that.

Really excited to hear that! If there is something you want to work on, feel free to ping me and I’ll try to assist you with it.

(Zicklag) #4

That’s pretty much what the plan is. I wrote a small doc outlining how we are thinking it will work so far. Very soon I’m going to be adding more documentation and a placeholder “roadmap” that will probably change drastically as we figure out what the system is going to look like put together.

Scripting will only be needed for custom logic and functionality and the Blender plugin will handle exporting all of the assets to glTF and RON files so we won’t need to load Blend files. We should be able to get a Blender scene running in an Amethyst game with no logic and just like an orbit camera without having any sort of scripting, so that is probably going to be our first attempt at a POC.

OK, sounds like a plan.

Awesome, that’s what I was hoping for.

Thanks! I’ll do that.

(Kae) #5

Hi! Great vision, sounds like it would be a joy to work with!

I have been working on Amethyst’s asset vision and would love to hear if there’s anything specific stopping you from using the planned asset pipeline for Blender integration.

For an overview of the scope, check out the repository: atelier-assets

(Zicklag) #6

Hey @kabergstrom I checked out the repo and I think it is a great idea. I had seen your RFC, but just hadn’t had time to read through it all yet. I’ll have to try it out; I’m definitely interested in using it for our project.

We really want to make sure that there are no bounds on the size of games that you can work on with this engine, while at the same time making sure that it is super easy to use, get installed, etc. Having a comprehensive asset pipeline will be critical, especially as projects get larger, like you’ve pointed out.

I’ll let you know if I have any thoughts on how that will fit in with Blender.

(Azriel Hoh) split this topic #7

A post was split to a new topic: Is Amethyst stable at this time?


OpenGL support in gfx-hal is WIP. And we have some progress.
Rendy’s support for gfx-backend-gl backend should come shortly after, it’s mostly about initialization.

(Zicklag) #9

As the first step in an initial Arsenal POC, I’ve started coding a glTF exporter for the Arsenal Blender plugin. You can see the code I’ve gotten so far here.

Something that we were really interested in trying out with Arsenal was implementing a Blender plugin in Rust. Because Blender plugins must use the Blender Python API, instead of writing the whole Blender plugin in Rust we wrote a thin Python layer around a Rust Python extension that does all of the work. Blender will load our Python plugin which, in turn, will make calls to our Rust Python extension. Using PyO3 we are then able to call the Blender Python API directly from our Rust code.

A large part of the motivation for writing the plugin in Rust was to increase performance. We wanted to make sure that you could export large scenes and meshes as quickly as possible from Blender. We weren’t exactly sure whether or not we would get large speed increases, though, because our Rust code would still have to go over the Blender Python API to get to the mesh data. The initial tests are very promising. In a scene with 376,000 vertices made up of 47 subdivided monkey heads, our glTF exporter finishes exporting the entire scene in 12 seconds. In contrast the official glTF Blender plugin takes 264 seconds to export the same scene on the same computer. That makes our exporter 22 times faster!

This isn’t exactly an apples-to-apples comparison because our exporter has a lot less features; it only exports vertices, vertex normals, and objects so far. If you look at the logs for the official glTF exporter, though, it shows that it spends all of its time generating the mesh primitives, which shows that it is not the lack of features that is making our exporter faster. The official exporter is much slower at doing what our exporter does do.

It is really exciting to start working on this project. We have got a long way to go, but we can start making progress a bit at a time. After we get the basic glTF export working with minimal features, we are going to try exporting a static scene from Blender and running it in an Amethyst game. The game won’t do anything, but you should be able to go from a Blender scene to a running Amethyst game in a single click.

We will be keeping the Arsenal Workboard up-to-date with what we are working on at the moment, and you can check out our roadmap to see what we are planning on working on next.

(Erlend Sogge Heggen) #10

Could this glTF exporter live in its own repository? It sounds like it could be useful to projects that might not require all of Arsenal.

Sounds good! Please post WIP screenshots of this as soon as you have them and we’ll share them on our feeds.

The progress you’ve made could already be mentioned on

p.s. you don’t really need a CLA if you’re planning to use the MIT license, as opposed to GPL.

(Zicklag) #11

Yes it could. For Arsenal we will only be interested in exporting to glTF, not importing, but if it gets to the point where it has basic features, we can look into packaging it as a standalone Blender export plugin. Eventually we might look into writing an importer too.

Will do!

Thanks for the tip. I’ll talk to my team about it.

(Zicklag) #12

Hey everybody, we just released the first version of Arsenal! It doesn’t do very much yet, but it is a good proof-of-concept.

We have builds of Arsenal for 64 bit Windows, Mac, and Linux and a Getting Started guide that tells you how you can test it out. We would love to hear what you think about it and what your experience was like if you try it out.