Draft: Add new buffer implementation

[voxelias]

This is a WIP PR with renderer refactoring.

• [x] New buffer implementation
• [x] Make Pipeline layout and Mesh layout ready for Storage buffers

[voxelias]

@QuantumEntangledAndy What do you think about the Buffer code?

[QuantumEntangledAndy]

Seems to be fine. Let see how it works in practice and go from there.

[voxelias]

Good, I will continue in this manner. First re-implement existing parts and re-arrange them in the module, then solve the layout issue. I want to avoid direct usage of all native WGPU components outside of renderer module, but keep this possibility for end-user for any kind of customization.

[QuantumEntangledAndy]

The use_as ones should be marked with #[must_use]

[voxelias]

Yeah, of course, I will solve all CI stuff in the end.

[QuantumEntangledAndy]

That's fair having them open for dev to customise would be useful.

I am working on the voxel/terrain stuff at the moment. Will be adding dotrix_voxel which handles rendering/marching cubing arbitary voxels, and dotrix_terrain which generates and updates voxels for the terrain. Direct rendering of voxels is coming along ok and I'm trying thinking about how it will fit in with marching cubes too.

[voxelias]

@QuantumEntangledAndy @Xaniaro If you are OK with this, I would love to merge it.

[voxelias]

I had a problem with differentiate Render, Renderer, RenderOptions structs

Render - is a Component, containing initial pipeline data with bindings, cycle counter and control(disable) flag. RenderOptions - GPU specific options for the pipeline (like Depth Buffer usage) that are not supposed to be changed during the Pipeline lifetime Renderer - is a service, as it was before.

Btw what are string labels used for? For storage, or some bindings in shaders?

This labels are being passed straight to WGPU. If something goes wrong, WGPU mentions this labels in debug output and you know where the problem is.

[Xaniaro]

Great. Thanks for explanation 👍