-
Notifications
You must be signed in to change notification settings - Fork 373
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
Add support for mesh vertex colors #1671
Conversation
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.
Awesome! Thank you so much for going the extra mile to add all these robustness & error handling improvements, as well as the splitting up of the vertex buffer. Loving all of it!
Haven't found any substantial errors/todos, most comments are "conversational" ;)
This thing is at least worth a dev-pulse post, if not more :).
Haven't run it yet, will do so tomorrow and then check what's up with the color interpolation on the triangle as discussed at the office (the color gradient seems to be a bit off, might be something about the perspective interpolation though).
@@ -243,13 +240,19 @@ fn import_mesh( | |||
anyhow::bail!("empty mesh"); |
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.
Really should get rid of all anyhow errors in all of re_renderer. One of the many things I never seem to get to :/
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 found that copilot was really good at writing thiserror
enum
s, so just do it
let vb_colors_start = vb_positions_size; | ||
let vb_normals_start = vb_colors_start + vb_color_size; | ||
let vb_texcoord_start = vb_normals_start + vb_normals_size; |
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.
[not actionable] I wonder if staging_buffer.extend_from_slice
should return these ranges as a convenience feature. What do you think? Helpful or too weird for an extend_from_slice
method? It's technically also different buffer ofc.
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.
This is tedious and error prone, so some helper would be nice
#[error("Invalid mesh given as input")] | ||
InvalidMesh(#[from] crate::mesh::MeshError), |
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.
The other errors are all about resource managers in general, so this should go to the mesh manager specifically.
However, the abstracted resource manager idea broke down quite a bit - e.g. I think I'll soon remove the "temp vs permanent resource" distinction; this didn't play out as I originally envisioned. So I'm ok if we punt on this :)
|
||
// ---------------------------------------------------------------------------- | ||
|
||
fn slice_from_np_array<'a, T: numpy::Element, D: numpy::ndarray::Dimension>( |
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.
How did we manage without this so far Oo
Co-authored-by: Andreas Reich <[email protected]>
Co-authored-by: Andreas Reich <[email protected]>
Co-authored-by: Andreas Reich <[email protected]>
Works with
rr.log_mesh
and with any vertex colors found n GLB/GLTF or OBJ files.Test:
just py-build && examples/python/api_demo/main.py --demo raw_mesh
Checklist