linebender / bevy_vello Goto Github PK

Implement text justification for the Vello Text API.

I cannot publish v1 of bevy-vello, since there are unpublished dependencies.

• vello (see linebender/vello#302)
• vellottie (dependent on vello)
• vello_svg (dependent on vello)

Wondering if it's completely out of the question to play nice with other bevy 2d renderers, such as bevy_sprite and bevy_smud?

https://github.com/johanhelsing/bevy_smud/blob/66d9249f33996b1c8d9ee2aee20b783ecdefa8ee/src/lib.rs#L593

I'm experimenting with Vello in a Bevy 3D project, where I have my cameras set up like this:

fn spawn_cameras(mut cmd: Commands) {
    cmd.spawn((
        Name::new("Main Camera"),
        MainCamera,
        Camera3dBundle::default(),
    ));
    cmd.spawn((
        Name::new("UI Camera"),
        UiCamera,
        Camera2dBundle {
            camera: Camera {
                clear_color: ClearColorConfig::None,
                order: 1,
                ..default()
            },
            ..default()
        },
        RenderLayers::layer(1),
    ));
}

With the intention being that anything that needs to be rendered in 2D-world-space as an overlay on top of the 3D scene should get RenderLayers::layer(1), so that it only gets rendered by the 2D camera.

However, when I tried to spawn a VelloSceneBundle with a RenderLayers::layer(1) component, it didn't render at all. After some debugging, I discovered that after changing the camera's render layers to RenderLayers::layer(0).with(1), the VelloScene started rendering as expected, indicating that bevy_vello's rendering systems are ignoring the RenderLayers component.

This is problematic for me, because allowing my 2D camera to render layer 0 causes it to render some other things that it shouldn't (e.g., 3D-world-space Gizmos with an always-in-front depth bias).

Edit: I just read over the discussion in #49, so it looks like you're already aware of the issue. 🙂 Let me know if there's anything I can do to help!

Rather than forcing the developer to use our layers, e.g.

commands
        .spawn(VelloVectorBundle {
            layer: bevy_vello::Layer::Background,
            ..
        })

Wouldn't it make sense to pass in a "z-ordering" or something universally useful?

We used layer as a quick and dirty painter's algorithm implementation but it would be better to use a "z-ordering"

Not sure if this is something known... short on time, sorry if it's a duplicate

rendered by bevy_vello:

svg in inkscape:

Probably would need to calculate the points of the non-rotated box, transform those points by either the affine matrix or a derived quaternion then draw those transformed points as connected lines to form a box

The VelloFont asset can be simplified down to Arc<Arc<[u8]>>. It's generally bad practice to wrap an Arc in another Arc because it requires two pointer dereferences on every access, which can hurt caching.

pub struct VelloFont {
    pub font: Arc<peniko::Font>,
}

pub struct peniko::Font {
    pub data: Blob<u8>,
    pub index: u32,
}

pub struct Blob<T> {
    data: Arc<dyn AsRef<[T]>>,
    id: u64,
}

// Or in other words
pub struct VelloFont {
    pub font: Arc<peniko::Font>,
}

pub struct VelloFont {
    pub font: Arc<Blob<u8>>,
}

pub struct VelloFont {
    pub font: Arc<Arc<dyn AsRef<[u8]>>>,
}

I propose VelloFont no longer wraps peniko::Font in an Arc and depends on Font to keep it shareable.

Currently we have transforms, global transforms, visibility, etc. inlined into each bundle (VelloSceneBundle, VelloAssetBundle, VelloTextBundle).

We should take the approach of splined and perhaps inline the SpatialBundle instead.

Constraints such as TextAlignment, etc. See the text example.

Debug visualizations (the white box and red X) don't properly show for assets in the screen coordinate space and are not augmented with a UI node.

Sorry if this question is stupid (bevy beginner here), but is it possible to set the transform origin of a VelloVectorBundle to the center of the vector instead of the bottom center?

I've seen the compute_local_transform in the parser, but it doesn't seem accessible in bevy world.

Thanks in advance for your input.

Minimizing window causes a validation error where X is zero:

wgpu error: Validation Error

Caused by:
    In Device::create_texture
    Dimension X is zero

bevy_vello should focus on a core API for scenes and rendering in Vello.

svg and lottie bring a significant amount of bloat to the library and we want to make those cargo features, as well as optional.

Any documentation buffs welcome, since, ideally, we want to

#[deny(clippy::missing_docs)]

Is there way to make this work with a 3dCamera, in the same way Bevyui targets the camera? This would mean avoiding two diferent cameras.

Debug visualizations (the white box and red X) don't properly show for text in the screen coordinate space.

Implement line break behavior for the Vello Text API.

I'm wondering if this crate would be the right place to provide mappings between Bevy and Vello primitives. Being able to use Bevy's Color and math types would make it feel more integrated when using the Scene API.

First, great work on this crate so far!

I'm evaluating using this for a project where it seems lottie might fit nicely, but I would need more fine grained than what this crate currently provides. An example effect would be a health bar that I can set to e.g. 80%, and then after taking damage it would animate towards 60%. Is it possible for this crate to expose an API that makes this possible?

Also, what is the recommended way to generate lottie files without using Adobe? I tried a bunch of stuff yesterday to convert one of my SVGs to no avail.