No idea why I can't get the basic 2d example working in my project

[goodiesohhi]

Basically copy and pasted the 2d example but with a render layer added on spawn (saw in the multicam example that was supported?)
Is there something I'm missing? All I'm trying to do is to just spawn the 2d example in my own project (the example works properly obviously when run as an example). I'm really struggling to figure this out I have no idea what I'm doing wrong, there doesn't seem to be enough moving parts to actually go wrong. I've literally just copy and pasted the 2d example and I can't seem to get it working. IDK what to supply for further assistance as it's literally just the example.

[djeedai]

@goodiesohhi thanks for the report, can you please try the example straight from the repo without modifying it? And if you can't repro that way, try applying any change to the 2d example directly (instead of the other way around). If you can get me a repro that way it would be a lot easier for me to investigate. Thanks!

[goodiesohhi]

I really can't seem to repro outside of my own project. And I can't seem to find anything that could conflict. Any ideas what could possibly cause this? The same code inside my project fails but works in the examples, everything to do with hanabi and cameras I've tried in both the hanabi examples and in my proj and it only fails on my proj.

[goodiesohhi]

if it helps I'm retrieving the handle like this from out of a resource, I can't figure out anything else that could be wrong tho

[djeedai]

There's nothing obviously wrong with that. But are you sure you're keeping the effect assets alive? I don't remember if Hanabi keep them for you, chances are it doesn't (to prevent cycling dependency and blocking asset unloading, in case that'd be desired).

[goodiesohhi]

how do you "keep assets alive"? I assumed adding the effect to the ResMut<Assets> was enough

[djeedai]

No, adding the effect to Assets<A> returns a handle with 1 reference. You can clone the handle and store it to add more references. If you don't have any handle, and the reference count drops to 0, the asset is deallocated from Assets<A>. This is a general rule for all assets in Bevy.

[goodiesohhi]

Okay but I am cloning the handle and adding it into a hashmap wrapped as a resource in bevy that should do the trick and this shouldn't be the issue right?

[VergilUa]

Having similar issue with bevy 0.13, bevy_hanabi 0.11 + features 2d when added to the existing project;
Same 2d example. Tried fireworks example - same result.

2024-06-15T17:17:29.413466Z ERROR bevy_hanabi::render: Failed to find init pipeline #15 for effect 43241v1
2024-06-15T17:17:29.413680Z ERROR bevy_hanabi::render: Failed to find update pipeline #16 for effect 43241v1, group 0
2024-06-15T17:17:29.420205Z ERROR bevy_hanabi::render: Failed to find update pipeline #16 for effect 43241v1, group 0

Any chance this is caused by multi-camera setup or added custom graphs?

[VergilUa]

Well, this is awkward.

So it turns out actual example particles do work. Its just particles are not visible enough.
Example lacks SpatialBundle (so it does not focus to the correct location via editor).
And particles are incredibly tiny in comparison to something like Ldtk imported project tiles.

Bumped speed and lifetime size to something like 5.0 and its at least in visible range.
Highly recommend bumping size and speed values for the 2d example.

Also, I've added dbg to the pipeline state, and it seems to be in Creating state upon first access.
Which triggers this error, but does not seems to cause any issues. E.g.:

 state = Creating(
    Task(
        Task {
            header: Header {
                scheduled: false,
                running: false,
                completed: true,
                closed: false,
                awaiter: false,
                task: true,
                ref_count: 0,
                metadata: (),
            },
        },
    ),
)

[djeedai]

Hi @VergilUa,

Bumped speed and lifetime size to something like 5.0 and its at least in visible range.
Highly recommend bumping size and speed values for the 2d example.

I don't understand why you don't see the particles, there's a screenshot in the examples/ folder and they're clearly visible. They shouldn't be that small. I just ran the 2d example again and even on a high-DPI monitor they're bigger than the mouse cursor.

Also, I've added dbg to the pipeline state, and it seems to be in Creating state upon first access.
Which triggers this error, but does not seems to cause any issues. E.g.:

I have no idea what that means. Is that a wgpu error or is that a particular error from the backend you're using (and which)? Does that mean that the pipeline didn't finish creating the first time it's accessed? That was my working hypothesis, but that shouldn't last more than a few frames. Although it's still worth fixing so the confusing error is not shown.

[VergilUa]

I don't understand why you don't see the particles, there's a screenshot in the examples/ folder and they're clearly visible. They shouldn't be that small. I just ran the 2d example again and even on a high-DPI monitor they're bigger than the mouse cursor.

I just copy&pasted the example into the existing project. Scene scale is about 10x larger, different camera settings, bright background, and a post fx layered on top. So yeah. It happens.

I have no idea what that means. Is that a wgpu error or is that a particular error from the backend you're using (and which)? Does that mean that the pipeline didn't finish creating the first time it's accessed? That was my working hypothesis, but that shouldn't last more than a few frames. Although it's still worth fixing so the confusing error is not shown.

That is a dbg! from the pipeline state [CachedPipelineState] for the case above.

let state = pipeline_cache.get_compute_pipeline_state(batches.init_pipeline_id);
dbg!(state);

Pipelines aren't created instantly, and since there's more than one graph being created at the same time - it seems to take more than a frame to do so. Error goes away after a frame. Probably worth checking for the state.

[djeedai]

I just copy&pasted the example into the existing project. Scene scale is about 10x larger, different camera settings, bright background, and a post fx layered on top. So yeah. It happens.

Ok makes sense. So the feedback here would be to maybe use an orthographic camera which is closer in size to the window resolution, as that's more common than the current one used in the 2d example (which sets the vertical window size to be 1 Bevy unit, so indeed makes everything small). Did I get that correctly?

Pipelines aren't created instantly, and since there's more than one graph being created at the same time - it seems to take more than a frame to do so. Error goes away after a frame. Probably worth checking for the state.

Ok that matches my gut feeling that the pipeline is sometimes not ready depending on the particular backend and GPU used. I think we're in agreement here. If so though, this means the error is only transient, and things eventually work, correct? Because I think in @goodiesohhi's case nothing renders ever, so it's not just that the pipeline is being compiled by the driver and needs more time, it looks a lot more serious.

[VergilUa]

Ok makes sense. So the feedback here would be to maybe use an orthographic camera which is closer in size to the window resolution, as that's more common than the current one used in the 2d example (which sets the vertical window size to be 1 Bevy unit, so indeed makes everything small). Did I get that correctly?

It depends on the project. But generally speaking, increasing size of the particles should be enough.
If people realize that FX are just too small [but visible], they are likely to to just bump the value. Or perhaps multiple FX with varying size should do the trick.

I'm using something like:

    OrthographicProjection {
        near: -1000.,
        far: 1000.,
        viewport_origin: Vec2::new(0.5, 0.5),
        scaling_mode: ScalingMode::FixedVertical(400.),
        scale: 1.,
        area: default(),
    }

If so though, this means the error is only transient, and things eventually work, correct?

Yep.