Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPU Particles #28

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

CPU Particles #28

wants to merge 5 commits into from

Conversation

james7132
Copy link
Member

RENDERED

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

@james7132 james7132 changed the title CPU Particles RFC CPU Particles Jun 22, 2021
@JonahPlusPlus
Copy link

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!

@james7132
Copy link
Member Author

james7132 commented Jul 8, 2021

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.

@djeedai
Copy link

djeedai commented Jul 16, 2022

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 ?

@james7132
Copy link
Member Author

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.

@cBournhonesque
Copy link

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants