In order to support all the math libraries, it would be useful if glsl-layout would support conversions from any type that can be converted into the corresponding mint type.

I put together something similar for the (flawed) shader-types crate, but with a derive macro I think the ergonomics can be even better.

Cargo.toml

glsl-layout = { version = "0.3.2", features = ["bigger-arrays"] }

main.rs

use glsl_layout::AsStd140;

#[derive(Copy, Clone, AsStd140)]
struct MyStd140 {
    array: [f32; 256]
}

Gives the errors:

error[E0277]: the trait bound `[_GLSL_LAYOUT_MyStd140::_glsl_layout::Element<f32>; 256]: std::default::Default` is not satisfied
 --> src/main.rs:3:23
  |
3 | #[derive(Copy, Clone, AsStd140)]
  |                       ^^^^^^^^ the trait `std::default::Default` is not implemented for `[_GLSL_LAYOUT_MyStd140::_glsl_layout::Element<f32>; 256]`
  |
  = help: the following implementations were found:
            <&[T] as std::default::Default>
            <&mut [T] as std::default::Default>
            <[T; 0] as std::default::Default>
            <[T; 10] as std::default::Default>
          and 31 others
  = note: required by `std::default::Default::default`

error[E0277]: arrays only have std trait implementations for lengths 0..=32
 --> src/main.rs:3:23
  |
3 | #[derive(Copy, Clone, AsStd140)]
  |                       ^^^^^^^^ the trait `std::array::LengthAtMost32` is not implemented for `[_GLSL_LAYOUT_MyStd140::_glsl_layout::Element<f32>; 256]`
  |
  = note: required because of the requirements on the impl of `std::fmt::Debug` for `[_GLSL_LAYOUT_MyStd140::_glsl_layout::Element<f32>; 256]`
  = note: required because of the requirements on the impl of `std::fmt::Debug` for `&[_GLSL_LAYOUT_MyStd140::_glsl_layout::Element<f32>; 256]`
  = note: required for the cast to the object type `dyn std::fmt::Debug`

Some graphics APIs like WebGPU require dynamic uniform offsets to be a multiple of 256. shader-types has a type named DymamicOffsetMember that helps with this, but it creates trailing padding bytes which interacts poorly with crates like bytemuck.

Would it make sense for glsl-layout to have a type like this? If it can calculate and add manual trailing padding to the AsStd140 version of the type, that would help avoid unspecified padding bytes.

It would be useful to be able to convert nalgebra types to glsl-layout types with an optional feature, just as is currently done with cgmath.

I'd be willing to give this a shot if a PR is welcome.

It is unsafe to view an arbitrary type as bytes because it might contain uninitialized padding bytes.

zerocopy solves this with a derive macro but it is a bit limited (it doesn't work with generics, and implementing it manually is discouraged)

Unfortunately many types in this crate have padding, so there isn't really a great alternative 😕

Hey hi, I would like to use glsl-layout to expose the Uniform macro from notan and I was thinking that because notan uses glam, to do that I need to convert with a macro from a struct with glam types, to a struct with glsl-layout types that is at the same converted to internal glsl-types to do the bytes conversion.

I would like to avoid this triple conversion and just do something like struct with glam types -> struct with inner glsl-layout types, do you have some hint to do that?

I am thinking of re-export the Uniform trait from notan without requiring the user to install directly glsl-layout, though I am not sure if that will work due to how derive macros imports types.

Anyway, I this can be summarized in that I would like to reuse and contribute to glsl-layout as much as possible without forking it to adapt to notan. It would be great if you have any hint that can guide/lead me to this.

Thanks!

std140 is probably the most common layout for GLSL types, std430 is also relevant.

Would it be in scope for this library to also support Std430 and AsStd430 traits?

Hello @zakarumych , I am preparing the update to glam 0.24 and saw that the test for glam fails in a weird way, I tested with 0.22 0.23, and 024, and all of them failed.

    let m3: mat3 = [[1.0, 0.0, 0.0], [0.0, 1.0, 0.0], [0.0, 0.0, 1.0]].into();
    let gm3_to_m3: mat3 = Mat3::IDENTITY.into();
    let gm3 = Mat3::IDENTITY;
    assert_eq!(m3.std140().as_raw(), gm3.std140().as_raw());
    assert_eq!(gm3.std140().as_raw(), gm3_to_m3.std140().as_raw());

Fails in the last assert with:

thread 'glam::test_glam' panicked at 'assertion failed: `(left == right)`
  left: `[0, 0, 128, 63, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 128, 63, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 128, 63, 0, 0, 0, 0]`,
 right: `[0, 0, 128, 63, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 128, 63, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 128, 63, 1, 0, 0, 0]`', src/glam.rs:83:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

There is some weird 1 where it should be a 0. Does this ring a bell for you? Any hint of what could be wrong? Thanks!