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

[Merged by Bors] - Allow passing glam vector types as vertex attributes #6442

Closed

Conversation

tim-blackbird
Copy link
Contributor

@tim-blackbird tim-blackbird commented Nov 1, 2022

Allow passing Vecs of glam vector types as vertex attributes.
Alternative to #4548 and #2719

Also used some macros to cut down on all the repetition.

Migration Guide

Implementations of From<Vec<[u16; 4]>> and From<Vec<[u8; 4]>> for VertexAttributeValues have been removed.
I you're passing either Vec<[u16; 4]> or Vec<[u8; 4]> into Mesh::insert_attribute it will now require wrapping it with right the VertexAttributeValues enum variant.

@mockersf
Copy link
Member

mockersf commented Nov 1, 2022

alternative to #2719 ?

@mockersf mockersf added A-Rendering Drawing game state to the screen C-Usability A targeted quality-of-life change that makes Bevy easier to use labels Nov 1, 2022
@tim-blackbird
Copy link
Contributor Author

CI is failing because I accidentally removed the following impls:

impl From<Vec<[u16; 4]>> for VertexAttributeValues {
    fn from(vec: Vec<[u16; 4]>) -> Self {
        VertexAttributeValues::Uint16x4(vec)
    }
}

impl From<Vec<[u8; 4]>> for VertexAttributeValues {
    fn from(vec: Vec<[u8; 4]>) -> Self {
        VertexAttributeValues::Unorm8x4(vec)
    }
}

but I'm not sure whether it makes sense to have these as [u16; 4] can be either Uint16x4 or Unorm16x4,
and [u8; 4] can be either Uint8x4 or Unorm8x4.

@mockersf
Copy link
Member

mockersf commented Nov 1, 2022

Failure is in example code. Can the example be improved to not use this From impl / be more explicit?

@alice-i-cecile alice-i-cecile added the M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide label Nov 2, 2022
Ok(value)
macro_rules! impl_from {
($from:ty, $variant:tt) => {
impl From<Vec<$from>> for VertexAttributeValues {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be inlining these trait impls? Do we have benchmarks or stress tests that might be able to spot a difference there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't find any that update vertex attributes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should add such a test. I think having stress tests that modify some of the data bindings (index / vertex buffers, textures, uniforms, storage buffers) every frame would be good for catching regressions. Currently we have multiple that update lots of uniforms with dynamic offset bindings (mesh entity transforms) and storage buffers (many_lights, on a system with storage buffer support which is basically everything except WebGL2). I suppose the compute shader game of life updates textures every frame, but it does it from a compute shader so there is no per-frame texture memory transfer from system to video RAM, but that would be good to test. And I don't think we have anything that updates index/vertex buffers.

Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much nicer. This is a good, internal only use of macros to reduce error-prone boilerplate.

@tim-blackbird tim-blackbird changed the title Allow passing Vecs of glam vector types as vertex attributes Allow passing glam vector types as vertex attributes Nov 2, 2022
@james7132 james7132 added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Nov 3, 2022
@alice-i-cecile
Copy link
Member

bors r+

@bors
Copy link
Contributor

bors bot commented Nov 3, 2022

Merge conflict.

Copy link
Contributor

@superdump superdump left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should not be merged before the Vec3A question is resolved. Beyond that, it would be good to add tests.

It would also be good to add a mesh vertex attribute mutation stress test but that can be done in a separate PR.

Ok(value)
macro_rules! impl_from {
($from:ty, $variant:tt) => {
impl From<Vec<$from>> for VertexAttributeValues {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should add such a test. I think having stress tests that modify some of the data bindings (index / vertex buffers, textures, uniforms, storage buffers) every frame would be good for catching regressions. Currently we have multiple that update lots of uniforms with dynamic offset bindings (mesh entity transforms) and storage buffers (many_lights, on a system with storage buffer support which is basically everything except WebGL2). I suppose the compute shader game of life updates textures every frame, but it does it from a compute shader so there is no per-frame texture memory transfer from system to video RAM, but that would be good to test. And I don't think we have anything that updates index/vertex buffers.

@superdump
Copy link
Contributor

bors r-

@superdump
Copy link
Contributor

Ok, I'm fine with the Vec3A issue now. But could you add tests for the various glam types, including ones that verify the resulting '.into()'ed vertex attribute values please?


#[test]
fn vec3a() {
let buffer = vec![Vec3A::ZERO; 10];
Copy link
Contributor

@superdump superdump Nov 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can appreciate if my push back is frustrating. My goal is to achieve really useful tests. The problem we were discussing about Vec3A, where my suspicion turned out to be wrong, would not show itself by using Vec3A::ZERO as all values are zero including the unused fourth f32 worth of bytes. Could we maybe used Vec3A::new(1.0, 2.0, 3.0). I wonder if there is any guarantee what that those f32-worth of bytes would be when using alignment. I don't know. My guess would be initialised to bitwise all 0.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair. This did cross my mind c:

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also note that all the others use 0s, but also they only really need to test the type conversions I guess. Vec3A is a special case, imo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, the fourth value is the same as the third.

impl Vec3A {
    pub const fn new(x: f32, y: f32, z: f32) -> Self {
        unsafe { UnionCast { a: [x, y, z, z] }.v }
    }
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My first thought is to maybe do the same for the third component as the fourth, in an attempt to avoid illegitimate floating point exceptions or something? I have no idea if that is the reason though. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we don't have to worry about this because it's not actually possible to use bytemuck on a Vec3A by accident!
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's good enough for me! :)

@superdump
Copy link
Contributor

bors r+

bors bot pushed a commit that referenced this pull request Nov 4, 2022
Allow passing `Vec`s of glam vector types as vertex attributes.
Alternative to #4548 and #2719

Also used some macros to cut down on all the repetition.

# Migration Guide
Implementations of `From<Vec<[u16; 4]>>` and `From<Vec<[u8; 4]>>` for `VertexAttributeValues` have been removed.
I you're passing either `Vec<[u16; 4]>` or `Vec<[u8; 4]>` into `Mesh::insert_attribute` it will now require wrapping it with right the `VertexAttributeValues` enum variant. 

Co-authored-by: devil-ira <justthecooldude@gmail.com>
@bors bors bot changed the title Allow passing glam vector types as vertex attributes [Merged by Bors] - Allow passing glam vector types as vertex attributes Nov 4, 2022
@bors bors bot closed this Nov 4, 2022
@tim-blackbird tim-blackbird deleted the glam-into-vertex-attribute branch November 8, 2022 21:52
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request Feb 1, 2023
Allow passing `Vec`s of glam vector types as vertex attributes.
Alternative to bevyengine#4548 and bevyengine#2719

Also used some macros to cut down on all the repetition.

# Migration Guide
Implementations of `From<Vec<[u16; 4]>>` and `From<Vec<[u8; 4]>>` for `VertexAttributeValues` have been removed.
I you're passing either `Vec<[u16; 4]>` or `Vec<[u8; 4]>` into `Mesh::insert_attribute` it will now require wrapping it with right the `VertexAttributeValues` enum variant. 

Co-authored-by: devil-ira <justthecooldude@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Usability A targeted quality-of-life change that makes Bevy easier to use M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants