blender-tools VS Magic Enum C++

I work at Embark Studios on our creative platform. Our team is building everything in rust.

Tons of big companies are using it: Amazon, Discord, Cloudflare, etc. You can read about their success stories. As for game development, Veloren is a pretty complex game, and it's written entirely in Rust. Embark is betting on Rust for their game dev projects. ECS makes the dream work here, but an Actor framework would work too. You don't need DI. For example, in the web services I write using Actix, application state (stuff like clients for redis or http, db connection pool, etc.) is stored globally, and shared through the application state extractor. No dependency injection, but accessing that global state is just as convenient as if it was DI. If it's shared across workers, you put it behind a mutex/rwlock or use a concurrent data structure.

https://embark.dev/ is a major player in the rust ecosystem right now. They look like they are aiming for more of a startup feel rather than an indie one.

We are at Embark! https://embark.dev/, https://embark.rs, https://embark.games.

Is a remote-first culture, Rust-only team building our game platform from scratch on all levels and all types of code (gameplay, engine, generalists, backend, research/ml), and with a strong focus on open source.

Tons of game studios are using Blender in production. And for environment creation 3dsMax is much more popular in games. 2 Blender examples: - Embark: https://github.com/EmbarkStudios/blender-tools - Ubisoft: https://github.com/ubisoft/mixer

What does this have to offer over magic_enum?

But it's a hack, and I prefer not to use hacks in production, because of their significant limitations:

Why reinvent the wheel? magic_enum

I strongly recommend that you instead use magic_enum::enum_cast

Magic Enum provides that.

While I can understand the sentiment behind that it makes for a poor solution because people seeing the enum will assume it's a valid entry. A better solution is to use something like magic enum for that case.

magic_enum by far. It has an extreme amount of black magic, and compiler specific stuff all abstracted away behind its extremely neat user interface.

magic_enum

To my knowledge magic_enum has some severe limitations; for example, it limits the range of enum values, it cannot handle duplicate enum values, it uses compiler-specific hackes, etc. There is a list of all of them here. [1]

And I'm glad to see interest! I can definitely add string -> enum conversion—I'll see if I can do that right now in fact, it might not take long.

[1] https://github.com/Neargye/magic_enum/blob/master/doc/limita...

It also has really cruel limitations, defaulting to MAGIC_ENUM_RANGE_MAX = 128! It will quietly fail if you try to use this with Vulkan enums for example.