Add sprite and mesh alteration examples #15298
Conversation
|
The generated |
alice-i-cecile
added
A-Rendering
There was a problem hiding this comment.
Good idea! The alter_mesh example could mayyyybe be turned into procedural_mesh, as that is what most people using this API will probably end up doing. Not sure, your choice.
The rest of the comments are just about how to make the examples a bit easier to understand for outsiders. Comments are mostly valid for both examples.
Good job with the examples, they're pretty nicely written!
|
I'm surprised not to see any usage of RenderAssetUsages here. |
I'm sorry, you might need to ELI5 here... how should I best use this? |
Couldn't make a decision either way, so left it alone. |
Read the docs https://dev-docs.bevyengine.org/bevy/render/render_asset/struct.RenderAssetUsages.html, and then let me know if you have any questions. I just realized the default is actually RenderAssetUsages::all() so that's why this example is fine, but I'd prefer if we could explicitly set that to all() and call out why it's necessary, as I very frequently see people make the mistake of using RENDER_WORLD only and then being confused why their asset does not exist. |
| // assets available in `Res<Assets<Mesh>>`. `RENDER_WORLD` alone will cause the asset to be | ||
| // unloaded from the asset server after it's been sent to the GPU. Unless you have a clear | ||
| // reason not to do so, it's best to use `RenderAssetUsages::all(). | ||
| |settings: &mut GltfLoaderSettings| settings.load_meshes = RenderAssetUsages::all(), |
There was a problem hiding this comment.
@JMS55 Is this the kind of thing you had in mind? New territory for me, so feel free to provide more direction!
There was a problem hiding this comment.
@JMS55 will know better than me, but IME it is the other way around: usually you won't be mutating meshes at runtime, so it's best to set it to RENDER_WORLD only unless you have a good reason to set it to ALL. Although IIRC for footgun reasons, we left the default at ALL.
There was a problem hiding this comment.
So JMS55 wrote:
but I'd prefer if we could explicitly set that to all() and call out why it's necessary, as I very frequently see people make the mistake of using RENDER_WORLD only and then being confused why their asset does not exist.
Perhaps if I make a point of only setting this to all for the asset whose mesh we're going to directly modify, and re-word the comment to say the default is "usually safe" unless you have more specific needs? I'll push that so you can have a read.
There was a problem hiding this comment.
The default is not usually safe, it is always safe, as the default is ALL. It's just twice as expensive than it needs to be for 99% of use cases, as nearly no one will be editing or inspecting meshes at runtime. Many people choose to use RENDER_WORLD instead of ALL for meshes, which is safe until you need to access the mesh on the CPU, which we do in this example.
There was a problem hiding this comment.
I'm with you now. OK, so maybe the second one we explicitly set it to RENDER_WORLD and add a further comment there. Maybe also modify the sprite example.
janhohenheim
added
S-Ready-For-Final-Review
|
Leaving it as waiting for author because of the render world thing |
Co-authored-by: Jan Hohenheim <jan@hohenheim.ch>
|
Thanks for being patient, I think I've arrived at a good place with the comments now! |
alice-i-cecile
added
S-Ready-For-Final-Review
|
I'm going to merge this once CI is green :) |
|
Argh internal imports again! One moment, caller. |
|
@alice-i-cecile sorted |
If this took a moment for you, that's a big indicator that our existing docs could be better in this regard. Happy to have an example showing and explaining the concept now :) |
Objective
Add examples for manipulating sprites and meshes by either mutating the handle or direct manipulation of the asset, as described in #15056.
Closes #3130.
(The previous PR suffered a Git-tastrophe, and was unceremoniously closed, sry! 😅 )