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

Implement layer effects #940

Merged
merged 26 commits into from
Nov 21, 2023

Conversation

OverloadedOrama
Copy link
Member

@OverloadedOrama OverloadedOrama commented Nov 11, 2023

Introduces a non-destructive workflow for effects/filters as proposed in #619.

2023-11-11.17-08-22.mp4
2023-11-11.17-07-18.mp4

All it does is essentially takes a copy of the images of the cels, uses ShaderImageEffect to apply each shader of every effect into the copy, and display that copy to the canvas (if Display Layer Effects is enabled) and to the exported image. The image data of the cels are not affected in any way, thus making it non-destructive.

The biggest issue with this system is performance. Drawing is noticeably laggier when effects are enabled, and this is due to RenderingServer.force_draw() that ShaderImageEffect is using. This method is necessary however, without it the resulting image is blank. A better solution may be this godotengine/godot#75436, or to use something like this godotengine/godot-proposals#7379.

The UI is different than the one proposed in #619, because I used a newer mockup by mrtripie which was posted on our Discord server. Feel free to give feedback!

To avoid code duplication with the destructive image effect UI and to future-proof the system, the parameter UI of the effects is being generated on the fly by reading the shader code and making the appropriate UI elements for each uniform (ValueSliders for ints and floats, CheckBoxes for bools, ColorPickerButtons for vec4s, etc). This system is future-proofed in the sense that we 1) don't have to update the UI every time a shader changes (although we have to do it anyway for the destructive image effects as of right now), and 2) it supports custom shaders loaded by the user, whenever we implement this feature.

Features not yet implemented, not inside this PR's scope:

  • Save the effect data on pxo, as well as the result images for easier importing (by third-party software) and exporting. Probably not going to work on it since the pxo format is subject to change, see Change the file format of pxo files #939.
    EDIT: This was implemented later, after this PR got merged, in 8c34532.
  • Support for animation, let properties change between frames and interpolate between them.
  • Let users load shaders. I was thinking that we could have a "Shaders" folder next to the "Brushes", "Palettes" etc folders where users can put their own .gdshader files, and for every shader file we would add both a destructive effect in the Image menu, and a non-destructive layer effect.
    - A way to permanently apply effects. EDIT: Implemented in cc8d18c and 5f7ae70.

@OverloadedOrama
Copy link
Member Author

Should be finished for now. I just implemented undo/redo support, as well as a way to permanently apply effects (destructively) to all cels of the layer. The main thing missing is pxo saving, but this can be handled after we deal with #939.

@OverloadedOrama OverloadedOrama merged commit 08b03ae into Orama-Interactive:master Nov 21, 2023
4 checks passed
@OverloadedOrama OverloadedOrama deleted the layers-fx branch November 25, 2023 01:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant