After updating to latest main branch, I get the following error when creating a spawner:

thread 'Compute Task Pool (5)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_bind_group
      note: label = `hanabi:spawner_bind_group`
    bound buffer range 0..592 does not fit in buffer of size 584
      note: buffer = `<Buffer-(64, 421, Vulkan)>`

This plugin, according to StarArawn who wrote bevy_ecs_tilemap, doesn't correctly set the z value for particle rendering: https://github.com/djeedai/bevy_hanabi/blob/main/src/render/mod.rs#L1606 .

This results in problems where the particles appear randomly below or in front of any of the sprites or tiles from bevy_ecs_tilemap.

I first mention this bug here: https://github.com/StarArawn/bevy_ecs_tilemap/issues/188#

Hello,

my application panics at thread 'TaskPool (10)' panicked at 'calledOption::unwrap()on aNonevalue', /home/marcel/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_hanabi-0.1.1/src/render/mod.rs:1173:62 I can't pinpoint/reproduce what is causing the panic, at the moment. I suspect it is some race between calling prepare_effects and queue_effects. Could you please help me debug the issue.

I added a ParticleEffectBundle as a child of my Player entity, however when despawn_recursive() is called, the particle don't despawn and stay there. Also the particle won't spawn a second time if the player respawns. Maybe I got wrong how to spawn and despawn particles bundle, didn't found any way of deleting / despawning particles in the examples.

Using bevy_hanabi fails in WASM because VERTEX_WRITABLE_STORAGE is not supported (even if WGPU doc says it is supported by all platforms).

Is it planned to make this crate WASM-compatible?

The upcoming bevy 0.9 comes with a slew of breaking api changes. They were substantial enough that I went forward with updating my bevy_hanabi branch to work with 0.9

Since 0.9 is a ways away, I'm leaving this as a DRAFT PR for the day when 0.9 lands.

The stock Bevy render pipeline allows cameras with the RenderLayers component to ignore entities without a matching layer mask (encoded with the same RenderLayers component). This allows multiple cameras to be used to construct a wide range of visual effects.

Particles currently render on all cameras, ignoring the RenderLayers component. This can result in conflicts between effects that use particles and effects that use multiple cameras. To support this Bevy feature, the particle rendering pipeline must detect the RenderLayers component on camera entities and allow layer-specific emitters or effect assets.

I'm not sure if I'm missing something obvious, but it seems that if I attach a ParticleEffectBundle to an entity, let it run for a while, and then commands.entity(entity).despawn(), the particle system just keeps emitting new particles at the last location of the entity.

I'm currently inserting a ParticleEffectBundle on every bullet in my game to create a trail of particles. When I despawn the bullets on collision, I occasionally get the following panic:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/render/mod.rs:1963:30

It seems like it might be a race condition regarding the bind groups.

Reproducible on my fork in the spawner-removal branch, in the remove.rs example: https://github.com/auderer/bevy_hanabi/blob/spawner-removal/examples/remove.rs

In my example, if you hold down the left mouse button to spam spawners, they will eventually panic while being removed.

Not sure if this qualifies as an issue, but I'm not sure how to get the particle system to work the way I'd like it to, and I'd really appreciate some help if you can spare the time :)

I'm using Bevy 0.8.0 and Hanabi 0.3.0 to simulate space dust in a 3D game, but the particles always render facing down the X-axis, and I'm not sure how to go about correcting them. I assumed the particles would always face the camera, but that doesn't appear to be the case.

When viewing the particle effect cluster from along the X-axis, it looks perfect:

When viewing from the Z-axis, the particles are barely visible, because they're perpendicular to the viewing angle:

I initially just tried to create two perpendicular particle effects to circumvent the issue, but the rotation component of the transform is also ignored by the renderer, which makes sense in hindsight, but I had to try :)

The code that I'm using to create the clouds is here My camera definition, which I suspect might be relevant is defined here. I'm parenting it to a "Ship" entity, which I suspect might be relevant.

Anyway, thanks for creating this plugin, even with this issue, the particle system is amazing and helped me get over a mental block!

The InitModifier and UpdateModifier traits were impossible to implement because the InitLayout and UpdateLayout struct were private.

This PR makes these structs publicly available. Shouldn't break any existing code that I'm aware of.

When spawning a new ParticleEffect, all particles disappear and existing effects will appear as if they had just been created. This effect can be seen in the example of #106. This seems to happen regardless of them using the same effect handle or a different effect.

When running some examples, like the spawn example, I'm getting the following error:

2022-12-25T15:02:28.965779Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default    
thread 'Compute Task Pool (0)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_texture
      note: label = `view_depth_texture`
    Dimension X value 2560 exceeds the limit of 2048

Looks like the problem is in this code:

    let mut options = WgpuSettings::default();
    let limits = WgpuLimits::downlevel_defaults();
    options.constrained_limits = Some(limits);

Examples should ideally work out of the box for everyone, so we might want to leave this (already option) section commented out or somehow detect the appropriate limits

The current particle attribute layout is hard-coded into the GpuParticle type:

https://github.com/djeedai/bevy_hanabi/blob/0f7494ddc58579bbfa379440d74fc72a071d8a51/src/render/mod.rs#L1117-L1129

It contains the position and velocity of the particle, its age, and its maximum lifetime after which the particle dies.

Although this is the most common set of attributes, some effects require more per-particle attributes, like the particle size (per-particle size variation/randomness), or its color, among many examples. To unlock building such effects, the particle layout should instead be dynamically determined by the set of modifiers which define the effect. This allows enabling a wide range of new effects while keeping the per-particle data as small as possible.

The idea is to define an Attribute type representing a single attribute of a particle, with a name (e.g. "position") and a value (e.g. vec3<f32>), and compose the minimal set of attributes needed per effect into a particle layout which determines how the per-particle data is encoded in the GPU buffer of particles.

It's common for particles to be animated using a spritesheet, allowing you to create effects like in this video.

I'm planning on working on this during the next week or two, so any feedback would be appreciated.

Current Plan

I'm going to update the RenderLayout struct to look like this:

#[derive(Debug, Default, Clone, PartialEq)]
pub struct RenderLayout {
    pub particle_texture: Option<ParticleTexture>,
    ...
}

pub enum ParticleTexture {
    Image(Handle<Image>),
    TextureAtlas {
        texture: Handle<TextureAtlas>,
        /// The index of the texture in the texture atlas.
        lifetime_texture_index_gradient: Gradient<f32>,
        /// How to interpolate between two textures in the texture atlas.
        texture_interpolation: TextureInterpolation,
    }
}

pub enum TextureInterpolation {
    Nearest,
    LinearBlend
}

In addition to the PARTICLE_TEXTURE shader key, I'll add a new PARTICLE_TEXTURE_ATLAS shader key, which will enable sampling a subset of the uvs following the configuration in the ParticleTexture enum.

Environment

bevy: 0.9 bevy_hanabi: 0.5 OS: MacOS

Issue

After despawning ParticleEffect entities, newly spawned ParticleEffect entities don't produce particles

Reproducing

See the following code for a reproduction: https://github.com/theon/bevy_hanabi/commit/132ce0b17050067e14c07935a8290a1cdd6b7177

The reproduction code spawns a new ParticleEffect entity every second. Once there are MAX_EFFECTS entities it despawns the oldest entity before spawning the next.

Setting MAX_EFFECTS in that example seems to determine when the issue starts:

• MAX_EFFECTS=1, 3rd spawned particle effect doesn't create particles
• MAX_EFFECTS=2, 4th spawned particle effect doesn't create particles
• MAX_EFFECTS=10, 12th spawned particle effect doesn't create particles

Example where MAX_EFFECTS=5 and the 7th spawned entity onwards doesn't produce particles: https://user-images.githubusercontent.com/759170/209003169-085f376e-8465-41cd-91a8-1649c318d691.mp4

Note: There is no issue when commenting out the line with despawn_recursive()

Currently we can spawn particles with a radial velocity and give them acceleration in an arbitrary direction. However, for some graphical effects, especially 3D ones, these options are not enough.

I suggest adding:

• Arbitrary initial velocity (for which there seems to be a stale PR draft)
• Tangential velocity, which gives a spin in the specified axis around the origin
• Radial acceleration, similar to the current spawning behavior but as acceleration (it might be possible to abuse force field modifiers for this, but I'm not sure if that is the desired solution)
• Tangential acceleration, same as the velocity but as acceleration
• Damping, reduces the speed of particles at the specified rate. Different from negative acceleration in that it can fully stop particles.

The user should be able to combine any of these on the same effect.

Sadly, since I'm not great at 3D space math, I can't add these myself. However I can provide you some example effects that would use these modifiers: Flame pillar: You spawn particles on the surface of a circle facing Y. Then combine Y+ velocity with tangential velocity. Whirlwind: You spawn partciles at the surface of a circle facing Y. Then combine negative radial velocity with tangential acceleration. Gathering ball: You spawn particles on the surface of a sphere. Then combine negative radial velocity with the right amount of damping so they stop near the center of the sphere Explosion+implosion: You spawn particles in just about any shape. Then combine positive radial velocity with negative radial acceleration.