thanks for sharing, aesthetic work like this is interesting!

the popping is caused by gaussian sort updates and mesh clipping. sort update popping will be resolved in the future (waiting on the wgpu radix sort /w subgroup support)

questions:

• this is generally feasible, though additional features would improve quality. balancing gaussian count/scale and performance would be required. multiple gaussian objects are currently not merged/globally sorted (planned feature), object occlusion/intersections will have popping.

• compute shaders driving the gaussian properties are possible. here is an example of compute node driven gaussian positions:
  

  bevy_gaussian_splatting/src/morph/particle.wgsl

  Line 52 in a8f6806

  position_visibility[point_index] = new_position;

a related project (a very useful reference for geometry -> gaussian compute shaders):
https://github.com/runevision/Dither3D

ideally, mesh skinning can be left native, where the compute shader is converting surfaces -> gaussians post-morph.

• by setting sh0 feature, sh is a single vec3, rgb -> sh can be done like sh = (rgb - 0.5) / 0.2821 (rgb can be derived from pbr render passes). making this more runtime configurable would be nice, maybe a configuration can support RGB more directly.

• the gaussian cutoff isn't a uniform/setting but it could be. it is found here:

  bevy_gaussian_splatting/src/render/gaussian.wgsl

  Line 219 in a8f6806

  let cutoff = 3.0;

the current configuration does clip edges of gaussians with full opacity.

• bevy 3D camera to gaussian cloud pipeline idea was initially creating multi-view bevy renders of a scene as test data for gaussian optimization pipeline testing. the final gaussian artifacts would be very similar to what you are describing, however, it'd be minimizing reconstruction loss instead of creating an aesthetically different scene.

I appreciate the example! I'll add a few suggestions. generally, I think work like this can definitely help iron out some of the wrinkles in the gaussian render pipeline and align the project towards game workflows

Thanks for the comments :) I applied the changes, asked for clarification on one.

Is that wgpu feature planned or on the way? If it’s only a rendering artefact then other experiments can probably proceed while waiting for it. Do you have a timeline for the global sorting?

I would presume that the memory for the gaussians for the real-time conversion would still have to get allocated on the rust side? Or is it possible to instance the gaussians for the meshes in the shader directly?

If you accept this example PR, next I could make the cutoff a uniform as a small warmup for the compute shader conversion example. I’ll do my best to do that one independently, but I would open a draft PR if I get stuck. Hope that’s not a bother :)