Renderer Refactoring

[voxelias]

According to recent updates it appeared that some changes are necessary to be done and some nice-to-haves as well. In this discussion I would like to raise up concrete issues and find the best solutions for them. The top topic will be updated

Blockers

• Current PipelineLayout and Mesh solution makes impossible to use StorageBuffer as VertexBuffer
• Differently typed buffers (VertexBuffer, StorageBuffer etc) around the same wgpu buffer makse no sense. Binding enum on is side will give more sense to choose how would you like to bind a buffer, whatever type it is.

Architecture Review

1. Add dotrix_renderer crate that will contain all traits and backend independent abstractions of renderer part
2. Add dotrix_wgpu as a first implementation of rendering backend, it will use and re-export dotrix_renderer
3. Crate dotrix_core will decide by the appropriate feature (that will defaults to wgpu for now) what crate should be used as renderer
4. WGPU itself can be re-exportedfromdotrix_wgpu, just as we have it in dotrix_eguiand each exported component can give a possibility of direct affect onwgpu` objects.
5. There should be a possibility to bind different buffers in different cycles (double buffers)

CC: @Xaniaro
CC: @QuantumEntangledAndy

[QuantumEntangledAndy]

For the buffer are we thinking of having one shared type that contains it's own BufferUsage that we check at runtime when binding?

struct Buffer {
  buffer: ...,
  usage: BufferUsage,
}

enum BufferUsage {
  ...
}

[voxelias]

We need to know buffer usage when we create a buffer. Then we need a possibility to bind it as and I am about to use existing Binding enum. So I am not sure we need to store it in the structure in property.

[voxelias]

In the end I decided not to rework crates structure and keep renderer inside of the core. If we will ever need to have alternate renderer, we will solve it.

[QuantumEntangledAndy]

So I am working on voxels and rendering them. The technique involves computing a signed distance field on the gpu when the voxel changes and rendering them.

This means two independent pipeline. One for computing the sdf and one for rendering.

Our current method involves spawning an entity with components such as (Mesh, Pipeline). However I am wondering if this could be changed to something like: (Mesh, Pbr) where Pbr holds the pipeline any any other relevant buffers that are needed for the pipeline. We could then have multiple alternative pipeline for a single Mesh like (Mesh, Pbr, Cartoon, ComputeBB). I am also thinking of variants like BatchPbr, which uses the techniques for rendering discussed in gpu driven rendering

Any comments?

[QuantumEntangledAndy]

Another thing to consider is how the meshes and textures are loaded. This should depend on how it is being rendered. A system might want to store them in seperate buffers or one giant buffer. This includes texture arrays and materials.

As an example, I wrote the voxel renderer wgsl to include trilinear textures for all 256 material ids on a voxel. However I had to remove it for now because it relied on the concept of one giant texture array on the gpu that could be indexed based on the voxels material id but we had no means setup to create a large texture array like this. So it is on the back burner for now.

[voxelias]

For the indirect drawing we will most likely have some separate global service that will handle giant buffers. I would not consider only one set of buffers per application for PBR. I believe there could be several even if pipeline is the same.

We need start with some simple example with 2-3 meshes with 2-3 materials rendered in one indirect draw call.

Then most likely the final architecture will be obvious.

[voxelias]

I was thinking a lot about how we store buffers and assets, how we link them. Maybe it will be a good opportunity to separate them.

[QuantumEntangledAndy]

I agree that we need more than one buffer. But as few as we can.

For meshes we'd need one that doesn't change often and some that can change. I'm thinking perhaps some sort of temporal grouping algorithm might help with this.

For textures I think we'd need different arrays for different texture sizes. Still not sure how to handle this dynamically. We could have a few buffers for standard sizes and one buffer for odd sizes that uses padding. We could also perhaps use binding group 3 for a series of texture arrays and tex id in the material has both binding id and tex array index.

[voxelias]

I think amount of buffers is defined by a project. We should provide a reliable way to maintain as many as necessary. But that is just a detail. We need some prototype to start with.

[QuantumEntangledAndy]

As another thing to consider refractoring. Perhaps we should think about the ECS. It would be convenient if we could:

1. Look up components for an entity
2. Add components to an entity
3. Delete components from an entity

As I understand it we currently do EC like this.

Maintain a list of component sets as in

One item will contain (Mesh, Tranform, Pipeline) and another will contain (Mesh, Entity, Pipeline).

These lists will have their own list off all components that have that combination.

I may be wrong in how I'm reading that code though.

If this is the way it is I think we should refractor it into a set of sparse lists indexed by their entity. Not have them grouped by sets of components. This would then make it easier to adjust these lists.

[voxelias]

In the current implementation of our ECS, entities are being grouped by Archetypes.

In the root, there is a Container which is a Vec of HashMaps.

Each HashMap contains all entities of specific Archetype.

Key of a HashMap is a Component's type ID. Value of a HashMap is a Vec of Components.

Entity is just a component added automatically to each Entity. You don't need to spawn it manually.

This concept made querying very fast. The limitation of this is a complication to add/remove components. We've accepted it with consideration, that we will create entities with full necessary list of components. If there is no some data at the moment of creation, the component my have Optional data.

Making of filtering should not be so hard. As long as Entity is just a Component we can make universal filtering. Could look like:

world.find::<(Entity, Speed, Health)>(|(entity, _, _)| entity == my_entity)

[QuantumEntangledAndy]

I see I supposed that the pre filter by archetype could help limit the searching. Perhaps this could be documented somewhere? An explanation of any design choices taken with their pros and cons?

[voxelias]

I definitely must start writing a Dotrix handbook in nearest future.