rfcs

rfcs copied to clipboard

RENDERED

This RFC proposes adding a fully featured CPU particle system implementation to Bevy.

Hey, I was really interested in creating something like this as well, but after looking at your code it seems like Bevy is going through a lot of changes with the render system, so I think I'm going to wait a little while until it's more stable. But I have a few ideas for how users can control values for things like position, 2D rotation, color, etc. So I figured you might be interested, especially if you are going to be the driving force behind this (I'm not too involved, so I don't know about who is doing what, but you seem way more experienced with this stuff). Essentially, it's a builder pattern for interpolation curves. It would look like so:

InterpolationCurve::build()
  .mode(mode: InterpolationMode::Linear)
  .push(value: 0.4, length: 20)
  .push(value: 0.2..0.3, left: 10, right: 20)
  .mode(mode: InterpolationMode::Cardinal)
  .push(value: 0.6, length 30);

The idea is that the lengths are relative (they don't have to add to 1); 20 will become 20/(20+30+30)=0.25. This could work with things like your CurveVariable::<Color> to control how long it takes to mix colors. Lengths can either be the midpoint (just length) or be represented by different parts for each side (left and right). mode can be used to change the InterpolationMode for that moment onward. This doesn't have to be just for particles, I'm sure it would work well for animation.

Also, I think ParticleEmitter should be a bit more generic. For instance, in my design I used a trait, so users can create their own emitters, in case they want to create patterns and what not. I know that your code is a prototype, so those built in functions could be placeholders, but who knows! I'm coming from seeing other game engines, like Unity, feel kind of bloated, when the tools aren't flexible enough for tasks that go outside of what it was made for. Kudos!

Essentially, it's a builder pattern for interpolation curves. It would look like so:

Seems good, the referenced Curve PR in the RFC could really use a better builder-like public interface. Though I think the eventual goal is to have it available in some general editor eventually instead of authoring it from code.

Also, I think ParticleEmitter should be a bit more generic. For instance, in my design I used a trait, so users can create their own emitters, in case they want to create patterns and what not. I know that your code is a prototype, so those built in functions could be placeholders, but who knows! I'm coming from seeing other game engines, like Unity, feel kind of bloated, when the tools aren't flexible enough for tasks that go outside of what it was made for. Kudos!

This is actually probably better to just keep it simple. Particles already has a public interface for spawning particles via ParticleParams. Nothing is stopping a developer from writing their own emitters that does not rely on the existing ParticleEmitter infrastructure.

Hey, I was really interested in creating something like this as well, but after looking at your code it seems like Bevy is going through a lot of changes with the render system, so I think I'm going to wait a little while until it's more stable.

Yeah this is why I'm waiting for the aforementioned animation curve PR and 0.6's render rework to land before opening a PR with this.

This very much look like the kind of feature that can be entirely investigated and implemented in an external crate without an RFC. Case in point is bevy_hanabi for GPU particles (I'm the author). What is the rationale for trying to add this as built-in @james7132 ?

Yes, this can be experimented with externally, and I am via https://github.com/james7132/bevy_prototype_particles (though that is slowly getting out of date with the rendering implementation), but ultimately I want this to be a first party crate at some point. The rationale is in the RFC: no competitive game engine is considered feature complete without some kind of implementation for particle systems. Also having a common implementation/interface allows the ecosystem to develop tools against it more readily (i.e. CPU-side modifiers). IMO, we need both a first party CPU and a GPU implementation to round out the rendering offering that Bevy has to be competitive with pretty much any other major game engine.

Just mentioning that this crate: https://github.com/abnormalbrain/bevy_particle_systems is a good example of CPU particles. (however particles are spawned as separate entities)