Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vertex buffers #1

Open
daxpedda opened this issue Jun 29, 2022 · 6 comments
Open

Vertex buffers #1

daxpedda opened this issue Jun 29, 2022 · 6 comments
Labels
enhancement New feature or request

Comments

@daxpedda
Copy link
Contributor

I am currently trying to use encase with wgpu, but got a bit confused when I tried to use it for vertex buffers.

As far as I could tell, the only difference between StorageBuffer and UniformBuffer is that UniformBuffer calls assert_uniform_compat.

So if I need to make a vertex buffer, am I supposed to just use StorageBuffer?
(worked fine so far by the way)

@teoxoy
Copy link
Owner

teoxoy commented Jun 29, 2022

Vertex buffers are a bit tricky to fit into the current design since they have a couple more limitations but also offer more flexibility at the same time. Only scalars and vectors should be allowed and there are also 8 bit and 16 bit variants that get mapped automatically to 32 bit ones in the shader.

I experimented with adding support for them a while ago but don't have anything concrete yet.

Do note that using the existing uniform/storage buffer warpers for this might not always work since vertex buffer items are tightly packed.

@teoxoy
Copy link
Owner

teoxoy commented Jun 29, 2022

I'd personally use bytemuck (for vertex buffers) for now since there is no extra padding needed for them.

@daxpedda
Copy link
Contributor Author

Thanks for the explanation, will do.

@kaphula
Copy link

kaphula commented Jun 6, 2023

I'd personally use bytemuck (for vertex buffers) for now since there is no extra padding needed for them.

Sorry for necrobump, but is there currently a solution for index buffers? As far as I know, if you have index buffer of u16 values for example, you need to pad them correctly. Casting arbitrarily sized index array through bytemuck can fail unlike vertex buffer.

Edit: Well I scrapped something for this case and it seems to work:

pub fn pad_index_buffer(buffer: &[u16]) -> Vec<u16> {
    let s = buffer.len() % 4;
    let mut gg = buffer.to_vec();
    if s > 0 {
        for _ in 0..s {
            gg.push(0);
        }
    }
    gg
}

@teoxoy
Copy link
Owner

teoxoy commented Jul 8, 2023

@kaphula &[u16] to &[u8] via bytemuck should work, the reverse might not (if the size is odd).

@simonask
Copy link

I think a significant use case (at least one that I have) is generating/modifying vertex data in a compute shader, in which case the layout must be compatible with both structs in storage buffers and the vertex attribute layout. It would be useful to support the subset of vertex attribute formats that are representable in ShaderType, which mostly comes down to providing a way to query the offset of fields for wgpu::VertexAttribute.

In my own use case, I just have my own derive macro that can generate wgpu::VertexBufferLayout requiring bytemuck::Pod and using std::mem::offset_of!(), but I would like to write vertex data using ShaderType (because the same data is accessed as storage buffers in compute shaders), and there isn't really any way to determine that the layouts are compatible.

I would use the new is_pod flag, but that isn't set for user-defined types (and I'm not sure how that would be possible in #[derive(ShaderType)]).

Would it be feasible/useful to go the same route as uniform/storage compatibility checks, i.e. something like assert_vertex_compat() (panics on rts arrays) and assert_storage_compat() (panics if vertex data contains u16 etc)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants