robtfm
robtfm
perhaps rather than requiring the trigger area to have a `MeshCollider` alongside it, we could add `mesh` and `collision_mask` fields to this new component (and maybe rename it to `MeshTrigger`)....
just wanted to confirm i see the same issue - 0.13 worked, 0.14 all good in desktop mode but in gaming mode my app is locked at just under 1fps...
https://github.com/user-attachments/assets/0fce6a59-6fa0-4bb0-aa29-d984c6a9d462
it does require copying the buffer (though using the lazy init, only when needed)... but it seems bevy does this internally for `TextMeasure`s already, so maybe it's not so bad....
> 4\. On some level I'd like to check and warn if the extension does not match the inferred type. However I'm not sure if this is the right spot...
> That is still necessary after #10153? Nice, I hadn’t seen that - I’ll check there’s no issues with using extensionless and then remove the “.image” extension
> Since there are multiple asset loaders registered which can handle an extensionless path for an `Image`. But that's beyond the scope for this PR. right ... the built-in ones...
maybe ... i tried to avoid changing the api of the main-world types (particularly `Image::data` which is pub) but maybe it's worthwhile
- added MeshExtractableData enum to avoid the nasty nested options / make the intent clearer. - added try_xxx functions to avoid 100s of unwraps in the cases where we know...
it would be nice to have a MeshBuilder with infallible access methods. then all the Mesh accessors could be result-based without scattering 100s of unwraps about. i don't think i...