Closed bilowik closed 1 year ago
This is difficult bc we can't read meshes like a texture unless we have a way to render it into a texture and then read from that.
Given that the shapes used to generate meshes all generate using a topography of TriangleList, we could just break up the mesh into it's smaller triangles. This would change all the calculations significantly though, it might be better to have a separate system for it.
We could even potentially break those triangles down even smaller. A quad will only ever have two triangles and that wouldn't be very visually consistent with the sprites particles. And a triangle.. would only have 1 haha.
Given that circles will have ~64 triangles, that's a lot of particles. We may want to settle on some kind of max value, and merge triangles into larger meshes until we meet that value. The issue here is that this is dependent on the order of the indices. If the indices are ordered in a way where neighboring indices aren't next to each other in order, then we can't make any assumptions on ordering. It might be best to just make that assumption and leave it up to crate users to ensure.
On that note, would it also be best to change the particle shapes to triangles for the sprite impl for consistency? Probably.
An alternative, is to use the aabb bounding box to estimate the size of the texture, create the texture and render the mesh into it. But is this even possible?
Supposedly rendering a Mesh to a Texture is not an operation that can be done in the confines of Bevy.
See #4
merged #9
Needs support for meshes. Currently only works for Sprites and TextureAtlasSprites.