7aed3e411d
# Objective - Alternative to and closes #19545 - Resolves #9790 by providing an alternative - `Mesh` is meant as format optimized for the renderer. There are no guarantees about how it looks, and breaking changes are expected - This makes it not feasible to implement `Reflect` for all its fields or `Serialize` it. - However, (de)serializing a mesh has an important use case: send a mesh over BRP to another process, like an editor! - In my case, I'm making a navmesh editor and need to copy the level that is running in the game into the editor process - Assets don't solve this because - They don't work over BRP #19709 and - The meshes may be procedural - So, we need a way to (de)serialize a mesh for short-term transmissions. ## Solution - Like `SerializedAnimationGraph` before, let's make a `SerializedMesh`! - This type's fields are all `private` because we want to keep the internals of `Mesh` hidden, and exposing them through this secondary struct would be counter-productive to that - All this struct can do is be serialized, be deserialized, and be converted to and from a mesh - It's not a lossless transmission: the handle for morph targets is ignored, and things like the render usages make no sense to be transmitted imo ## Future Work The same song and dance needs to happen for `Image`, but I can live with completely white meshes for the moment lol ## Testing - Added a simple test --------- Co-authored-by: atlv <email@atlasdostal.com> |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
Bevy Internal
