Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alpha should apply to layer as a whole, not every element in layer #37

Open
dominikh opened this issue Aug 10, 2024 · 6 comments
Open
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@dominikh
Copy link

When modifying the with_winit example to render with a non-unity alpha, such as

renderer.render(lottie, frame, Affine::IDENTITY, 0.5)

the result looks like
image
with each component of the tiger having alpha applied to it individually. Instead, the alpha should apply to the rendered image as a whole.

I suspect, but haven't confirmed, that the same issue exists for layers specified by the lottie file.

@simbleau
Copy link
Member

simbleau commented Aug 10, 2024

This is known.

There's a workaround for full-image alpha:

(apologies for formatting, this is copy/pasted from bevy_vello)

let scene_buffer = Scene::new();
let scene = velato...render(...);


                            scene_buffer.push_layer(
                                vello::peniko::Mix::Normal,
                                *alpha,
                                *affine,
                                &vello::kurbo::Rect::new(
                                    0.0,
                                    0.0,
                                    asset.width as f64,
                                    asset.height as f64,
                                ),
                            );
                        }
                        scene_buffer.append(scene, None);
                        scene_buffer.pop_layer();

@simbleau
Copy link
Member

@dfrg or @DJMcNab or @waywardmonkeys - Do we have any opinions about whether we should change the render method to match user expectations for alpha?

@simbleau simbleau added the question Further information is requested label Aug 10, 2024
@dominikh
Copy link
Author

Considering this also applies to layers and groups with transparency, what would be the reason for not changing the behavior? Just to reduce the number of clip layers? Because as is, Velato will not correctly render any layer or group with transparency that contains overlapping shapes. That is, this problem isn't specific to the alpha parameter of append.

@simbleau
Copy link
Member

I think I agree, this could be easily fixed and a PR would be appreciated.

For historic context - If I recall correctly, some of the friction was that you need a shape to clip by, and that's not always correct or obvious. For a lottie file, we could use the asset.width and asset.height to clip by, but there's no bounding box you can query by for a general vello Scene. I think there was talk on making the shape optional, so we can guarantee correctness on lotties which spill outside of their widthxheight boxes.

@simbleau simbleau added bug Something isn't working good first issue Good for newcomers and removed question Further information is requested labels Aug 10, 2024
@dfrg
Copy link
Contributor

dfrg commented Aug 10, 2024

@dfrg or @DJMcNab or @waywardmonkeys - Do we have any opinions about whether we should change the render method to match user expectations for alpha?

I’d say it should either be fixed or the parameter should be removed since the behavior is clearly incorrect. If lottie layers are exhibiting the same problem, which seems likely, we should surround them with vello layers when alpha is non-unity.

@DJMcNab
Copy link
Member

DJMcNab commented Aug 12, 2024

I agree, we should probably use a Vello layer here. I think we probably should have an issue in Vello tracking the implementation of linebender/vello#623

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants