polish compute_mesh example

[JasmineLowen]

• remove "chunk" wording that is irrelevant at this point
• improve DataRanges Uniform
• add Globals uniform and recompute mesh each frame

---

[ChristopherBiscardi]

I'm not convinced by the motivation here (well there isn't any motivation listed in the PR description actually, as of this comment). Regenerating the mesh every frame is not the purpose of this example and is the default behavior if you run a compute shader so doesn't really need to be exemplified. The implication in the example is that the compute is somewhat heavy and should be done once. For example: generating terrain chunks around a player.

I'm also not convinced by the custom abstractions for set_vec3/get_vec3. These seem to add more indirection that I'm not sure is actually helpful.

So these are changes, but not for any stated purpose afaict. It's just a different example now which in isolation is fine. I guess we could have a simple "generate mesh every frame" example and a separate terrain chunk example.

[alice-i-cecile]

could have a simple "generate mesh every frame" example and a separate terrain chunk example

Mhmm, grounding this stuff in real world patterns that people might actually want and putting them in the usage examples seems like a better path forward to me. It makes these sorts of questions about "what should we teach and why" a lot clearer.

[JasmineLowen]

Hmm good points. I'll update the description a bit more tomorrow.

I personally read the example as a very basic intro into creating a mesh with a compute shader and rendering it with the bevy mesh pipeline.

I totally see the use case for chunks and huge meshes in general that you are describing (I actually also do that in a personal project!). But I guess then we (or I) should split this into a separate example that is a bit more refined around that topic.

Currently it was kinda confusing to read about chunks while rendering two cubes. I also think that an example with some truely huge mesh would reveal some other pain points. For example the allocation of an empty mesh as it's currently done in the existing example takes some time and leads to stutter if its big enough.

The idea about the regeneration each frame came from my personal journey lately. The last thing I did was render compute generated geometry with a custom pipeline on every frame. But that meant losing the good parts of bevys mesh pipeline like the pbr lighting. In contrast to that, you could use the compute mesh example approach to get all the nice parts of bevys mesh pipeline IF your mesh is small and cheap enough to be regenerated each frame. Here, a better allocation strategy would probably also improve the example.

[beicause]

Regenerating the mesh every frame is not the purpose of this example and is the default behavior if you run a compute shader so doesn't really need to be exemplified. The implication in the example is that the compute is somewhat heavy and should be done once. For example: generating terrain chunks around a player.

In my opinion, computing the mesh every frame is exactly the biggest advantage of compute shaders and a more common use case, because it avoids uploading data from CPU, while the advantage of computing it only once is often less significant.

[JasmineLowen]

In my opinion, computing the mesh every frame is exactly the biggest advantage of compute shaders and a more common use case, because it avoids uploading data from CPU, while the advantage of computing it only once is often less significant.

Well to some degree Chris is right. I didn't notice he recently landed a new example for mesh rendering via a compute shaders. I think this is a better way to render with compute than my changes here with the small animation.

Nevertheless, I guess splitting the example in a very basic one and an intermediate one would be a good idea.