{%hackmd @themes/dracula %}
# aravoxel, 2024 gameplan
aravoxel has finally somewhat started "real" development. That being said, it's still early and somewhat experimental.

The main one I've worked on is `aravoxel-wgpu`, made entirely from scratch using `winit` and `wgpu-rs`. There is no game engine here, so all rendering is on me.

This one is obviously the hardest one to work on as I don't really have any idea on how to do a lot of things, but things are working well so far.

Will need to do a check on performance.

# aravoxel-wgpu
After having gone through the "relevant" things in the wgpu-tutorial we have now started generating voxels.

There is a flow that does the following:

- Sample noise to generate a landscape. Currently only decides if the voxel is solid or not.
- Draws the voxel in the "simple" way. It checks each neighboring voxel and only creates vertices/indices for the correct sides.
- If the neighboring voxel is outside of the local chunk, it also checks the neighboring one to see if it should draw or not.

This flow works. Making the generation itself and allowing different blocks is the next step.

That being said, I have to implement a *lot* of things still, when it comes to the game itself. Not a challenge I'm opposed to, but due to the difficulty of getting good lighting, fog, PBR materials, physics, etc, working without any experience, it's still valid to check if my current generation logic can be applied to existing frameworks.

# aravoxel-bevy :heavy_check_mark:
Bevy is a code-first game engine with a focus of being "data driven" written in Rust. It has a fully featured ECS, which can be used without bringing the engine in. So theoretically, you could work with Bevy without the engine part.

That being said, this is about using Bevy the engine. Integrating wgpu and winit and all into bevy-ecs is more than doable, but at that point I might as well just keep doing the wgpu version.

Using the engine will have the many benefits that come with using one. Lights, PBR support, all that good stuff.

Tasks:
- Set up a camera
- Port the generation / building flow
- See if I like Bevy

### March 14th
*"I decided to go through with it today. First time I used Bevy was last year and I wasn't entirely understanding the flow behind ECS leaving me more confused than anything (but when you decide to learn Rust, voxel generation while also tackling a new paradigm like ECS that's expected, I guess...), but now I feel like I actually understand the concept and how to use it. It's quite intuitive - but I still have a lot to learn.*

*As written above, the bevy version currently has a free-flying camera, and has a way to lock/unlock your cursor from the game.*

*While the majority of the generation and mesh building logic could be ported 1:1 with only slight modifications, there was a little bit of time that went into building a bevy mesh rather than data with buffers.*

*In Bevy, a Mesh is a single chunk, rather than the entire landscape, and they are laid out as expected. The performance is more or less 1:1 with the `wgpu` project, which isn't entirely unexpected since Bevy is also using Rust + wgpu in the background. But nice to have that confirmed.*

## Benefits:
- The ECS.
- The built-in bundles, such as lights, PBR, UI, etc.
- Plenty of plugins available for raycasting and physics, such as Rapier.

## Conclusion:
- Other than not being experienced with ECS programming (being more familiar and at home with OOP), I am seeing the benefits of it. Once you understand the flow being resources, components, and queries, you get a lot of power. It's not too hard to structure the project either.
- Performance itself is good, too.

*Bevy is powerful, and while previously I wasn't a fan due to not really understanding the flow of ECS, now when I have more Rust experience it comes more naturally. There's a lot you can do very efficiently and cleanly that neither Godot or my `wgpu` version wouldn't be able to do.*

*There are worries with Bevy, however. Despite it's power and relative ease-of-use, it comes at a cost: Bevy is young - currently sitting at version 0.13. It's actively developed and moves very fast, and as such it often has big breaking changes. This also means that they haven't made a proper documention page on it yet, and many examples and guides (that aren't the official ones) are outdated and no longer functional.*

*That being said, perhaps that's not a bad thing and could offset the fact that I'm not doing my own engine from scratch.*

**As such, Bevy is something I definitely could see myself work in when it comes to `aravoxel`.**

# aravoxel-gd :x:
Godot is obviously a fully-featured game engine. One I have experience in.

Part of me would like to use it. But performance concerns are very much... there.

### March 12th

*"There is currently an unfinished version of it using an adapted version of `wgpu`'s drawing/generating. That being said, SurfaceTool seems to choke on complex meshes. Reading through the documentation, this is "as intended" and the tool isn't made for "complex meshes"*

*I don't want to give up on Godot yet, so let's see how the performance is affected when using ArrayMesh instead of SurfaceTool.*

### March 13th
*After having changed some implementation details I got to the point where it generated a chunk and drew it correctly. Issue that became painfully obvious, however, was that the drawing was incredibly slow even with just a single chunk. In Bevy and WGPU I drew a grid of 5x5x5 Chunks in a matter of seconds, Godot crashed my PC. While every version of aravoxel will eventually require to delegate drawing to threads to speed things up, here it was necessary from the outset.*

## Benefits:
- ArrayMesh/SurfaceTool is easy to use. Creating normals, UVs, and applying color is easy as pie.
- All the other built-in goodies that Godot has.
- Community plugins and shaders.
- My experience, obviously.

## Conclusion:
- Godot is not inherently made to make procedural voxel landscapes like this. It *can* do it, as I've proven, but even the official "voxel example" in the repos state that just using Godot built-ins and GDScript is inherently limiting. Sure, I could try to use C# instead of GDScript, but the official concensus is "*You're better off using a custom solution, like the godot-voxel fork.*" But since I want to do the generation myself...

*Godot is powerful, and I have a lot of experience with it. That said, for this project in particular, it won't be a great fit. It feels good to have this on paper, though. I tried.*

**As such, Godot is ruled out for this project.**