bevy_hanabi

[native elbow]

Note that you won’t be able to do “set emitter position, spawn, set another emitter position, spawn again” within one frame, because the position of the emitter is extracted at the end of the main frame into the render world. And anyway we upload a single transform per emitter.

[tender pulsar]

right yes

[weary abyss]

I've thought about the ability to upload particles directly, e.g. from OpenVDB data

I think it would make sense as an option. We'd probably need another "upload" shader

[near zealot]

has anyone run into panics that say this?

Buffer with 'hanabi:buffer:spawner' label has been destroyed

[tender pulsar]

how do i know when an instance of an effect is done, so i can despawn it? or should i keep them around for reuse?

[gilded fox]

I'm saving their spawn duration and lifetime

[tender pulsar]

well ok sure and then what?

[gilded fox]

let effect_entity = commands
                    .spawn((
                        ParticleEffect::new(pieces_effect_handle.clone()),
                        EffectMaterial {
                            images: vec![particle_image.clone()],
                        },
                        transform,
                    ))
                    .id();
                timed_despawn_requester.write(DespawnAfterTimeRequest {
                    entity: effect_entity,
                    duration: BOSS_HURT_PARTICLES_SPAWN_DURATION + BOSS_HURT_PARTICLES_MAX_LIFETIME,
                    maybe_time_scaler: Some(TimeScalerId::GameTimeScaler),
                });```

Then when that time is done I despawn it

[tender pulsar]

ok makes sense

is there a way to save a WriterExpr expression as a let inside the shader, so i can reuse the expression in multiple different init modifiers? WriterExpr can be cloned, but afaik that duplicates the entire expression

part of why i ask is there's some .uniform()/.rand() calls in there and i don't want it to generate new random numbers

[gilded fox]

This error is driving me mad, it looks correct in the code but then not in practice

Does anybody have a Local particle effect that works for them?
Maybe I'm missing something?

[tender pulsar]

oh this is Attribute::F32X3_3 etc are for

[tender pulsar]

did you get an answer to this?

[sour dock]

nope

[weary abyss]

we'd need more of a repro

[native elbow]

See #1036006050526142514 message from v0.17 where it was already reported, so unlikely to be a 0.18 version issue. My best guess as I mentioned on GitHub is that some pipeline or shader for some fullscreen effect (maybe bloom?) is not ready. Maybe some rendering expert would have an idea? (CC:@quasi wharf for example)

[gilded fox]

I have a reproduction here just saying 🥹

[quasi wharf]

yeah, we experience pink screen on macos at startup due to ordering issues when pipelines aren't ready. it's metal basically barfing. if i had to guess your intuition is correct and it's some weird combination of a pipeline not being ready

i don't think we have this log available, but it would be helpful to have a cache miss log on fetching pipelines that we could dump, i bet that would be pretty easy to spot

[clear wigeon]

IIRC it's related to either the tonemapping or upscaling pipeline not being ready?

[native elbow]

Agreed with Patrick, depth collision would be amazing, I've put it off because I didn't have the knowledge to fetch Bevy's depth buffer and didn't have time to investigate, but otherwise it's probably a good self-contained change.

[native elbow]

Note for context: I'm trying to re-add batching, which in practice means:

• init and update pass (will) work on a single GPU buffer containing several instances of the same effect, as opposed to currently a sub-view of that buffer over a single effect instance
• I extensively use prefix sum to find which effect instance a particle (or other) is part of
• everything currently referencing a single effect in an EffectBatch is bound to disappear
  That being said it's a long change with plenty of issues currently so not near landing. At the minute it works without ribbons, but I need some refactor of the EffectMetadata buffer to make it work for ribbons too.

[cloud solar]

I guess regards to the issue being opened on bevy_hanabi is whether or not we have this issue tracked in bevy itself (I do recall in either 0.16 or 0.17 the pink screen bug was introduced and there’s at least one other issue opened re pink screen: https://github.com/bevyengine/bevy/issues/20756).

I don’t mind if the hanabi issue has to be closed but if it’s been hard to replicate in bevy itself, the issue seems to be reproducible at least so may be useful.

[native elbow]

I don't mind leaving it open, but as I mentioned I probably won't do anything about it myself. If anyone on the rendering team wants to have a look they can use your repro indeed.

[weary abyss]

This is exciting! Once you do this I'll see about getting all my other changes upstreamed

[native elbow]

That might take a while though 🙁

I've looked at some of your other changes, I wanted to try upstream as much as possible, but we need to discuss them (later), some I don't understand and some I'm skeptical about.

[split quail]

There is something new in bevy_hanabi in the new version or just update version to 0.18

[native elbow]

minor things like https://github.com/djeedai/bevy_hanabi/pull/504 but otherwise just 0.18

[native elbow]

For example https://github.com/djeedai/bevy_hanabi/pull/487/changes#diff-7855ff7260a5c914d647351f9477312b1347f2c9455814700954dd6a51718781 it's a chicken and egg change, EffectMetadata has a spawner index and SpawnerParams has a metadata index. At some point you can't batch, you need a prefix sum to find either one or the other.

EffectMetadata is particularly annoying; it contains data on GPU we need to keep frame to frame, but if we want to keep the entries packed and/or ordered to simplify batching dispatching, then it makes allocating/deallocating for new effects quite complex.

I'm thinking of keeping them in batch order like spawners, and then using a ping-pong buffer each time there's an allocation to handle the moves

[weary abyss]

The LUT one is the one I figured you might be skeptical of, but I don't know what you'd prefer

[weary abyss]

@native elbow Awesome work toward upstream batching!

[tender pulsar]

sooooo what repo/branch should i be using for most up-to-date batch spawning? i've had to abandon work on integrating particles several times over because i keep having issues and need to switch tasks to something other than particles

i did manage to get hanabi to take particle colors from sampling a provided texture

looks like i used https://github.com/djeedai/bevy_hanabi@main

oooohhh right but i had to use an older commit (https://github.com/djeedai/bevy_hanabi/commit/db782db43a03e8dbea41043f832fd5d5e468406f) because for some reason the bind groups were mismatched

[haughty merlin]

any news about cube position of shape initialization?
Asking because it is something I need and I think I saw a mention of initialization methods possibly changing, so I am not sure if I should spend my energy trying to do a PR

[tender pulsar]

like, i think i would benefit from batched processing? but ok so i am still struggling to figure out how to make my particle needs fit within what bevy_hanabi is capable of.
the biggest thing is i want to be able to do batched spawning that seems beyond what's offered by mashing some expressions together. two examples:

• taking a static image and exploding it into a cloud of particles which start in an arrangement that would look like that static image for the first frame before flying apart. i kind-of have this working on a fork of bevy_hanabi that modifies ParticleTextureModifier so i can sample the colors of a texture. maybe that's good enough.
• imagine that water is represented as a tilemap in a 2d platformer, so you can have arbitrary arrangements and shapes of water which aren't easily represented by a single AABB. each individual water tile needs to be capable of spawning particles that flow to give the impression of water current flow. i could make an individual spawner instance for every single water tile, but that seems .. excessive? maybe that's fine, but i've been worried that would be far too many instances. maybe i could make a big vector of AABBs and consolidate adjacent tiles together as much as possible into a minimal set?

i'm really close to making my own particle engine heh. i feel like my needs aren't fulfilled by any of the bevy libraries i've looked at

[native elbow]

You mean spawning particles over a cube shape? That’s a reasonably easy modifier or expression to write. We could merge it as it’s probably common enough, but you can do it without any change today.

[native elbow]

What you need here I think for all your use cases is something I think @weary abyss might have already done, but I’m otherwise interested in getting: read (and why not, write too) of arbitrary GPU buffers as additional data sources from the various passes. This is slightly involved in that you need to manage those resources for all effect instances and bind them appropriately. But definitely a feature in the scope of Hanabi.

[weary abyss]

there is a thing called a Lut in my branch that allows you to do such things, as long as you can pack it into a texture

it could be expanded to support arbitrary buffers too

[native elbow]

Ah yes LUT that’s it

The static image explosion is a feature I want, although more for 3D meshes. Definitely a must.

Sampling from a generic 3D mesh in general is useful.

[weary abyss]

I originally introduced it for curves because the artists were making complicated curves that were too much of a pain to evaluate analytically so I just bake them into a texture and sample

note that in that case I do need the bilinear filtering, which is why I did textures instead of buffers first

[haughty merlin]

i was unaware how flexible hanabi was, sorry, I thought I was constrained into PositionModifiers only.
I will go with a personal solution then, thanks.

[tender pulsar]

i can pack it into a texture yeah. which branch is this? i was trying to ask before because i feel like i've lost track of what's happening with the various branches

if i want to do an arbitrarily-sized batched spawn per Update, does the way systems all flow together mean that i should be able to modify a texture every Update and it's "seen" by the shader in the same tick?

i have been unsure about data latency when using textures to plumb data from CPU to GPU

or .. i suppose textures and buffers are two separate things as well. heh

[weary abyss]

https://github.com/pcwalton/bevy_hanabi

[weary abyss]

yes, I believe so

[tender pulsar]

and, as far as you know, the examples on this branch should be runnable under the released bevy 0.18.1? just want to make sure .. because i was getting runtime failures on macos last time i tried. i might've been doing something else wrong

[weary abyss]

I haven't tested macOS

[tender pulsar]

right ok

so i'll try that now

[tender pulsar]

@batched? just making sure

[weary abyss]

yeah

[tender pulsar]

ok here we go

2026-03-25T21:15:23.150719Z ERROR wgpu::backend::wgpu_core: Handling wgpu errors as fatal by default

thread 'Compute Task Pool (3)' panicked at /Users/hab/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wgpu-27.0.1/src/backend/wgpu_core.rs:1233:26:
wgpu error: Validation Error

Caused by:
  In Device::create_bind_group, label = 'hanabi:bind_group:init_indirect_batch'
    Binding size 64 of Buffer with 'hanabi:buffer:batch_descriptor' label is less than minimum 256


note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `Enable the debug feature to see the name`!

thread '<unnamed>' panicked at src/render/mod.rs:7773:22:
Init indirect batch bind group must be present
Encountered a panic in system `Enable the debug feature to see the name`!
Error: ExampleFailedError(1)

this was just target/release/examples/worms

[weary abyss]

macOS-specific restrictions, bleh

I'll fix it at some point

[tender pulsar]

i can try to fix it if i know what the restriction is

i haven't needed to futz with wgpu this deeply

[weary abyss]

I think it's that you have to bind minimum 256 bytes of a buffer on macOS

[tender pulsar]

right ye that is what the error says .. and i can find the line batch_descriptor_buffer.set_label(Some("hanabi:buffer:batch_descriptor"));
but i'm not sure where it's getting the size from

[weary abyss]

probably from the bind group

it's either the init_indirect_batch bind group or the init_indirect_batch bind group layout

[tender pulsar]

ahhh.. right ok

[native elbow]

Not really. It’s the storage buffer align. Apple is only less nice (256) than nvidia (32) for example. But it’s a well defined standard rule.

min_storage_buffer_offset_alignment

[tardy pecan]

Hello! I am wondering if it's possible to change the simulation speed of particle on a per-effect basis. I am aware there's EffectSimulation.set_relative_speed() but that's for all particles right?

I am looking to create some sort of bullet time effect where my controlled character's animation and particles plays in normal speed while enemy particles and animation slows down. Is this possible with Hanabi? If not, how difficult is it for someone like me to modify it to do this?

[haughty merlin]

you will want to add_property() to create a variable that can alter Attribute::VELOCITY .
then you will have to add EffectProperties to your particles entity to control that property

[tardy pecan]

so the idea is to create a property that changes Velocity & Particle lifetime and stuff like that on the fly? hmm... it's not the solution that I'd like but I suppose it's a good stopgap solution

[haughty merlin]

sorry I misunderstood completely, I assumed you were only talking about velocity. and not simulation speed overall.

I also once was interested in simulation speeds for stuff like cooking particle effects off screen

best I could find is altering Attribute::AGE and Attribute::LIFETIME to varying results

[tardy pecan]

yeah modifying those properties directly might interfere with stuff i'd imagine down the line.

[broken moss]

Anyone get hanabi working 0.18 on macos without a pink screen? I assume its Metal and not a quick workaround, but in case there is wanted to ask, saw a thread point here

[broken moss]

Solved, it was Bevy

"hanabi 0.18 panics on Metal" was a false attribution. Real cause was a custom-Material WGSL shader hardcoding @group(2) from the Bevy 0.14 era. Bevy 0.18 reorganised bind groups so that group 2 is now a GPU-driven mesh storage buffer — the shader's var<uniform> declaration mismatched the pipeline layout's storage binding, wgpu panicked and pink screen for me.

[cloud solar]

Are you saying this bug was in your code or it’s in bevy hanabi code?

[broken moss]

Bug in my code

Hanabi being introduced caused it to happen but the code was the issue. Using samply I was able to zero in on disabling hanabi, which worked but then reading online made me think it wasnt hanabi itself 🤷

[near zealot]

I'm looking at using hanabi for rain and it works pretty well but I'm kinda wanting something that looks like a splash when a rain drop hits the ground (or a mesh?)... but I suspect there's not a good way to do that and I have to fake it somehow, right?

[tardy pecan]

don't think there's any collision atm. Maybe try KillAABBModifier and have a child particle for on death?

[worthy reef]

In case anyone is interested, I've started integrating bevy_hanabi into my game via bevy_mod_scripting and here are the bindings so far: https://github.com/makspll/arcane_assembly/blob/710a85f50f4d89610c62e6d3f25a7448d9ed8bf1/src/particles/bindings.rs, the expression graph plays very nicely with lua / reflection: #1357045538884816966 message

[tardy pecan]

this is kinda driving me a bit nuts, are ppl's rust-analyzer complaining about Gradient? Compiles just fine...

[bold ocean]

Could try using fireworks or sprinkles instead. They have collision.

[near zealot]

I'm getting this too

[weary abyss]

Yeah, collision is the main thing missing from Hanabi(-Batched) right now. You could set a condition that spawns mesh particles into another effect when their Y value reaches a certain amount as a workaround

[native elbow]

Yes this is a collision of names with Bevy itself. There's another one with AlphaMode. I don't understand why the analyzer fails to pick the correct one though.

[gilded fox]

Is it possible to set an effect's color dynamically? (Like how one can set the simulation space to local and change the effect's transform dynamically)

[tardy pecan]

yep, totally doable
if you are looking to change it depend on some action, check: https://docs.rs/bevy_hanabi/latest/bevy_hanabi/properties/index.html

[gilded fox]

Thanks, taking a look

I can't figure out- would it take priority over other color modifiers?
I have a color-over-lifetime modifier, and would like to be able to modify it to fade out in the middle of the effect
Currently the only solution seems to be... creating something that changes color over lifetime and multiplies it by an opacity prop I'd be able to control from outside

[tardy pecan]

I mean the fade out for color over lifetime thing, is that always consistent timing or just fading out on some sort of trigger

[gilded fox]

So
I have an enemy which as a part of its move set might emit a few seconds long particle effect
When this enemy is killed the particle effect stays, and I'd rather have it fade out with the enemy on death
The effect particles already have a color-over-lifetime (consistent) change, but I'd like to be able to trigger something that overrides that into fading out entirely, and then destroys it

Although, I just realized I could just shrink the effect, since its simulation space is local
Might not look as elegant but it looks like an easier solution

(Thanks)

[tardy pecan]

In that case yeah I think property is the right tool. Just have your color expression written with both color over lifetime and an alpha value multiplier over the attribute. And lerp the property in a system.