Switch to new renderer

[terrarier2111]

This renderer solves a lot of our issues and its written in rust using wgpu which means we support all relevant graphics apis. Link to the new renderer: https://github.com/wgpu-mc/wgpu-mc But sadly we have to wait until this project is usable.

[birbe]

You should be able to get started as soon as I get rendering pipelines finalized. Shouldn't take too long, maybe a couple of days or less.

[birbe]

Actually, I just did it. https://github.com/Birbe/wgpu-mc/blob/bb259366565fcbb35a82d0b6547ebef3df910c64/wgpu-mc/src/render/pipeline/mod.rs#L23

This trait allows you to create a custom pipeline in the renderer. You make use of this while calling WmPipeline::render, seen here https://github.com/Birbe/wgpu-mc/blob/bb259366565fcbb35a82d0b6547ebef3df910c64/wgpu-mc/src/lib.rs#L248

[terrarier2111]

Actually, I just did it. https://github.com/Birbe/wgpu-mc/blob/bb259366565fcbb35a82d0b6547ebef3df910c64/wgpu-mc/src/render/pipeline/mod.rs#L23

This trait allows you to create a custom pipeline in the renderer. You make use of this while calling WmPipeline::render, seen here https://github.com/Birbe/wgpu-mc/blob/bb259366565fcbb35a82d0b6547ebef3df910c64/wgpu-mc/src/lib.rs#L248

Is chunk and model rendering etc already implemented?

[birbe]

Chunk rendering is somewhat implemented but I was actually a bit hasty as I have to work out how data should be properly provided to the WmPipeline's to keep everything non-blocking when rendering, while still being able to update the renderer's state from multiple threads. Sorry about that. I'm actively working on this

[birbe]

I took a hiatus but I'm back working on it. I switched the most important stuff over to arc_swap, meaning that reads should be much faster (and non-blocking) with writes being simple as well. WmPipeline is also working now, and blockstates are being worked on (but mostly implemented, I just have to fix block mesh generation being screwy for some reason).

I think now could be a good time to get some basic code structured out within Leafish integrating wgpu-mc. I'm testing things out using the demo crate, so that can be used for examples, but I'll provide an explanation here for the structure of wgpu-mc. From here on out I'll switch out between calling wgpu-mc it's full name, along with just "wm".

Resources

pub trait ResourceProvider: Send + Sync {
    fn get_resource(&self, id: &NamespacedResource) -> Vec<u8>;
}

ResourceProvider is a trait which must be implemented. This takes in a &NamespacedResource which is a tuple struct of (String, String), used to represent things such as textures or block models. Wm also uses this to get it's shaders, so if you're ever changing say, resource packs, then the underlying data that your implementation of ResourceProvider references is what would be changing (from wm's point of view). This also makes it easy for you to allow user-provided shaders as nothing like that is hard-coded into wm, they just have to be provided under the "wgpu_mc" namespace in the resources, however you choose to provide that.

Blocks. They're not fully implemented (e.g. multipart) and I broke some stuff in the move to supporting blockstates but the external API usage shouldn't really change. Leafish doesn't use datapacks at the moment, and wm uses them, but you could technically implement custom deserialization structures for yourself. I might have to change how certain things (like block models) recursively deserialize each other, but it won't be anything too complicated. Either way:

Blocks are initialized by providing WmRenderer.mc.block_manager with deserialized Blocks. These describe what states a block can take along with the corresponding models.

Next step is baking the blocks. This should be as simple as calling MinecraftState::bake_blocks, and it should just handle the rest. This will process all the variants, their models, and bake them into meshes along with any transformations. Multipart will require more work, but that's a relatively low priority.

Chunks

Wm makes use of a BakedChunk struct in order to keep track of VBOs. The method to generate a BakedChunk is located within the Chunk struct, but that probably needs to be extracted and made more generic, so that you don't need to store chunk data twice in memory (in WM form and Leafish's form).

Rendering chunks is done using the WorldPipeline struct which wm provides, however you can re-implement this however you'd like if you choose.

GUIs

This is entirely up to Leafish to decide how to implement. To render anything through wm, you make use of WmRenderer::render(&self, wm_pipelines: &[&dyn WmPipeline]). You get to decide which pipelines (and in which order) are rendering at any given time, so you have total freedom to implement a GUI.

Pipelines

Mentioned above. Here's the trait.

pub trait WmPipeline {

    fn render<'a, 'b, 'c, 'd: 'c, 'e: 'd>(
        &'a self,

        renderer: &'b WmRenderer,
        render_pass: &'c mut wgpu::RenderPass<'d>,
        arena: &'e bumpalo::Bump);

}

All of the important stuff is located in the renderer field, which gives you a &WmRenderer to play with. You're also given the render pass, and an arena, to which you can allocate anything any resources that you'll need. (mostly Arcs from within the ArcSwaps).

Closing

I'm very actively working on wm, and I'm making a lot of progress so it's still in its early stages, but the API is maturing enough that if you'd like, you can look into how it would fit into Leafish. Hopefully I didn't leave anything too major out.

[birbe]

Finished refactoring entity rendering (which is instanced, so free performance). Animated textures were also implemented by another contributor but I'll also refactor that a bit. Leafish doesn't use datapacks apparently which isn't exactly a hindrance when you make the switch but you will have to figure out yourself how you want to represent data in Leafish in the wgpu-mc formats

[terrarier2111]

We will be using a fork of wgpu-mc which is located here: https://github.com/terrarier2111/wgpu-mc

[terrarier2111]

This is done because AFAICT Birbe is very opposed to the idea of using wgpu-boilerless in wgpu-mc, but i already used wgpu-boilerless in major portions of the rewrite and it will make the entire process of switching the renderer much easier

[terrarier2111]

This will probably mean, that we won't have a very up-to-date version of wgpu-mc in the future and we will only update if there are major advancements which justify the effort

[terrarier2111]

I found a way that probably enables us to use both wgpu-mc and wgpu-boilerless together, it will take some time however to implement it, this will enable us to simply use upstream wgpu-mc

[Kuratius]

Is it known how wgpu-mc compares to this? https://github.com/xCollateral/VulkanMod

[birbe]

Is it known how wgpu-mc compares to this? https://github.com/xCollateral/VulkanMod

(theres no chance of leafish using that minecraft mod as the replacement renderer as its 1. written in java and 2. for minecraft)

[Kuratius]

Is it known how wgpu-mc compares to this? https://github.com/xCollateral/VulkanMod

(theres no chance of leafish using that minecraft mod as the replacement renderer as its 1. written in java and 2. for minecraft)

I'm asking in terms of how complete the feature set is. Based on your answer I'll assume that nobody looked into that.

It seems that wgpu-mc is also ultimately intended to be usable with a fabric mod, though that mod doesn't seem to exist right now.

This doesn't mean that this can be used for leafish, I'm aware of that, but if the goal of wgpu-mc is to end up with the same functionality then if it's more conplete in terms of feature set asking how it implemented those features is a legitimate and relevant question.

[birbe]

sorry if I misunderstood. I am the creator of wgpu-mc. The fabric mod definitely exists, and there is a mostly up-to-date README you can look at to see how far along wgpu-mc is