Hi everyone, a few months ago I posted the announcement that I’m working on a metaverse engine, this article is to explain the current state/progress of the engine. I don’t want the (currently nonexistent) hype train for the project to exceed what’s actually going to happen so I am to be completely transparent in these updates and I’ll try (and fail) to not overpromise.
Also it looks like these updates are going to be a little rambley as they’re essentially going to be serving as brain dumps for what I’m thinking about. Sorry in advance.
Current Status
So lets cut right too it, what can the engine currently do? Both a lot, and not much of anything. In it’s current state all you see when you start it is two rotating wirewhiz logos, not very impressive; but there is a lot going on there. For one, it is done using the custom ECS framework that I have built. All the data for the spinning logos is stored in components, and updated using systems.
ECS
This is a bigger deal then it might at first seem. This is because the ECS framework I have built is based around creating types at runtime. What does that mean? Well in languages like c++ all types, things like classes, structs, basic variable types, etc… must be defined at compile time. Or in other words when you build the program. This is a little bit of a problem if you want to support an infinite multiverse. For one you’d need a supercomputer just to finish your build before the heat death of the universe. Obviously I don’t have access to a computer like that.
Some coding languages already can define new types at runtime. C# for instance has something called reflection. Due to being a interpreted language, meaning that C# is stored as a universal byte code rather then pure machine code and must be run using an intermediate program instead of directly on the CPU, it has inherent support for that sort of thing. Similarly JavaScript must deal with the same problem. It’s mostly used on the web meaning that it has to be able to run on any browser without that browser having been compiled with access to all the javascript in the world.
The thing is, though the languages I mentioned above could technically do the job, and are are fast, and even have JIT solutions to port themselves to machine code, they’re not fast enough for me. That’s why I made C++ support runtime generated types.
I created a system that allows me to create “virtual structs” at runtime and them use those as components in the ECS framework, I also made it so that normal structs work seamlessly as well. Giving the engine those native c++ speeds, with the flexibility of an interpreted language.
But is it actually fast? I don’t know, I haven’t come up with any good benchmarks yet.
Graphics
I have not put a ton of work into the graphics yet. I got it to the point that it’s working and I’ve decided to pause work on it until I get the asset loading framework put together. But here’s what I have so far:
Runtime compiling of shaders using glslang, I also have caching the spirv code working.
A simple materials system that can create new materials at runtime. In the future I would want to modify it so that it can automatically grab things like uniforms from the shader code and use that. (Or at least verify stuff like that.)
Muli-object rendering. Right now it’s all a single render pass using sub-buffers with a separate draw call for each object. But the way that materials currently work it will be relatively easy for me to get instanced rendering working in the future. The next step is to load in a model and have that spinning around instead of a quad, but again I want to get the asset management system working before doing that.
Asset Management
This is probably the most important part of the engine aside from the ECS. (Since it’s kind of the whole point) I have nothing but plans so far in this area. I’ve begun work on mapping out how servers are going to work. Even made a hello world program that can interface with a database. But the work in this area is just beginning. I’m thinking that I’m going to have two different types of servers, one for the runtime, and one for assets. The runtime server will actively sync players, while the asset server will be what people download stuff from. So in short, runtime server thinks and asset server remembers.
This is what I’m currently working on. Right now I’m figuring out how to manage multiple build targets with CPain (CMake) and then it’ll be on to downloading files off of the server. I’m aiming to get our first rotating server downloaded model working in around two months.
Vision Disscussion
And now on to talking about future vison, I’ve recently been thinking a lot about how the server side of BraneEngine is going to work. I’ve come to the conclusion for now that while I don’t want to release the source code anytime soon, I do want to release the engine itself for free. It just isn’t a metaverse if nobody is using it right? The way I plan to go about doing this in the short term is for the client build to be freely available and the server build(s) will be something like a patreon exclusive thing (of course only once it’s ready for that).
Why give out server builds if I want to have a connected metaverse though? Well it’s precisely for that reason that I’d also be distributing the server code. The project will get off the ground a lot quicker if multiple people are running their own private servers. To connect them all together I plan to have a system that allows one server to “reference” the assets on another server. Essentially making it so that you can bring whitelisted items from server to server. If you’ve ever worked with JavaScript think of it as importing a library from an http address. You don’t own the item but you can use it. If you haven’t caught on yet, this entire project is essentially going to be a glorified web browser.
