Bevy v0.15.0

[elaye]

#86

[simbleau]

This PR looks great!

A few questions, I'm still trying to answer:

• Instead of <MyHandleComponent>.0 everywhere, I think it would be nicer to use .id(). This requires MyComponentHandle to derive Deref and DerefMut
• Is there yet a convention on what to name these newtypes for Handles? I've seen several cases where Bevy renamed them to have "2d" at the end, e.g. MeshMaterial2d

[simbleau]

Another note, which is somewhat unrelated, is that certain logic should be able to be eliminated or optimized with new features in 0.14/0.15.

Specifically, the spawn_playheads function exists to attach a playhead to a newly added Lottie. This is a good job for required components (or observers). Ideally I really want to split Svg and Lottie into their own types, rather than both being used by VelloAsset, but that feels like a different PR.

[simbleau]

AH, one more catch: The VelloAssetBundle, VelloTextBundle and VelloSceneBundle now no longer require global transform, view visibility, or inherited visibility. Those are required components brought in by Transform and Visibility now.

[elaye]

Regarding the Handle names, I don't think there is a convention yet. If we look at an example of the migration from bevy, they changed struct Mesh2dHandle(pub Handle<Mesh>); to struct Mesh2d(pub Handle<Mesh>); but it's hard to find an equivalence with VelloAsset and its handle. We could use VelloAsset for the handle name but we would have to come up with another name for the wrapped struct, that's why I used VelloAssetHandle as it seemed simpler.

As for the migration to bevy 0.15 features, you're obviously right! However I didn't want to make the PR too big. I figured a first PR could make it work with 0.15 and a second PR could make it more idiomatic :)

[simbleau]

Btw I got some errors that the vello_svg::vello::Scene and vello::Scene versions are mismatched. Not sure if you see those too. Can't tell because our Cargo.lock isn't staged.

@DJMcNab or @xStrom - Was it determined that all linebender projects will stage the Cargo.lock?

[elaye]

Yes I have the same errors when I run cargo check --all. It seems that vello::Scene and vello_svg::vello::Scene come from two different versions of vello, probably because I used unreleased versions, making things inconsistent.

[RobertBrewitz]

I thought I'd chip in a little as I dabbled with this during 0.15 release candidate process, and I remember I was stuck for a few hours on why extracted entities kept piling up duplicates in the render world; As I did not know about this new retained render world feature in 0.15.

Unless 1) some sort of resource structure is implemented to keep app world entities and render world entities in sync or 2) spawn extracted entities with the TemporaryRenderEntity component so they despawn after every frame, they'll keep being spawned every frame and never be removed from the render world.

Edit: Deriving ExtractComponent onto VelloScene and VelloTextSection and using the ExtractComponentPlugin might be enough to make it work with minimal effort.

Hope it helps!

[DJMcNab]

linebender/rfcs#5 led to the agreement that we would commit Cargo.lock.

[msvbg]

Hey, what’s the state of this PR? Is anyone pushing it forward?

[simbleau]

Hey, what’s the state of this PR? Is anyone pushing it forward?

Yes, there is a longer-than-expected delay in vello 0.4.0 coming out which is holding this PR up.

Bevy 0.15 depends on wgpu 23, and the last version of vello (0.3) uses a prior version of wgpu.

[RobertBrewitz]

I've been playing around a bit more with a fork and at the time of writing, we have to update the specialize function to get transparent base_color working; Relates to linebender/vello#549 which is not in the 0.4.0 milestone any more for some reason.

fn specialize(
        descriptor: &mut RenderPipelineDescriptor,
        _layout: &MeshVertexBufferLayoutRef,
        _key: Material2dKey<Self>,
    ) -> Result<(), SpecializedMeshPipelineError> {
        if let Some(target) = descriptor.fragment.as_mut() {
            let mut_targets = &mut target.targets;
            if let Some(Some(target)) = mut_targets.get_mut(0) {
                target.blend = Some(vello::wgpu::BlendState::ALPHA_BLENDING);
            }
        }

        let formats = vec![
            // Position
            VertexFormat::Float32x3,
            VertexFormat::Float32x2,
        ];

        let vertex_layout =
            VertexBufferLayout::from_vertex_formats(VertexStepMode::Vertex, formats);

        descriptor.vertex.buffers = vec![vertex_layout];

        Ok(())
    }

[simbleau]

Velato is very close, which will unblock this.
linebender/velato#49

[simbleau]

I've been playing around a bit more with a fork and at the time of writing, we have to update the specialize function to get transparent base_color working; Relates to linebender/vello#549 which is not in the 0.4.0 milestone any more for some reason.

fn specialize(
        descriptor: &mut RenderPipelineDescriptor,
        _layout: &MeshVertexBufferLayoutRef,
        _key: Material2dKey<Self>,
    ) -> Result<(), SpecializedMeshPipelineError> {
        if let Some(target) = descriptor.fragment.as_mut() {
            let mut_targets = &mut target.targets;
            if let Some(Some(target)) = mut_targets.get_mut(0) {
                target.blend = Some(vello::wgpu::BlendState::ALPHA_BLENDING);
            }
        }

        let formats = vec![
            // Position
            VertexFormat::Float32x3,
            VertexFormat::Float32x2,
        ];

        let vertex_layout =
            VertexBufferLayout::from_vertex_formats(VertexStepMode::Vertex, formats);

        descriptor.vertex.buffers = vec![vertex_layout];

        Ok(())
    }

Noted! Looking into it.

[simbleau]

There appears to be a regression on this branch.

The images are not getting cleared every frame, see cargo run -p lottie

[simbleau]

After some digging Im still not sure why the frame buffer doesnt clear

[RobertBrewitz]

After some digging Im still not sure why the frame buffer doesnt clear

Is it that you are not adding TemporaryRenderEntity to the extracted entities in the extract systems?

Edit: this would be the quick fix I suppose

[simbleau]

After some digging Im still not sure why the frame buffer doesnt clear

Is it that you are not adding TemporaryRenderEntity to the extracted entities in the extract systems?

Edit: this would be the quick fix I suppose

Ah, beautiful!

Infact this was the issue.
https://bevyengine.org/learn/migration-guides/0-14-to-0-15/#spawning-entities-in-the-render-world

[simbleau]

This looks ready to me (there seems to be a new CI issue though)