-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[Merged by Bors] - Allow passing glam
vector types as vertex attributes
#6442
Conversation
alternative to #2719 ? |
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 |
Failure is in example code. Can the example be improved to not use this |
Ok(value) | ||
macro_rules! impl_from { | ||
($from:ty, $variant:tt) => { | ||
impl From<Vec<$from>> for VertexAttributeValues { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
Vec
s of glam
vector types as vertex attributesglam
vector types as vertex attributes
bors r+ |
Merge conflict. |
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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.
bors r- |
6b30996
to
d2a54aa
Compare
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]; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 }
}
}
There was a problem hiding this comment.
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. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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! :)
bors r+ |
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>
glam
vector types as vertex attributesglam
vector types as vertex attributes
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>
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]>>
andFrom<Vec<[u8; 4]>>
forVertexAttributeValues
have been removed.I you're passing either
Vec<[u16; 4]>
orVec<[u8; 4]>
intoMesh::insert_attribute
it will now require wrapping it with right theVertexAttributeValues
enum variant.