Add shader-based smooth transitions between presets#741
Merged
kblaschke merged 20 commits intoprojectM-visualizer:masterfrom Nov 16, 2023
Merged
Conversation
Also cleaned up the code a bit, the version string format is well-defined by the standard - we just have to cut off anything after the space if there is any.
It's only referenced from within TextureManager, plus we can reuse the noise generator for other things.
Also added the required shader files. Still need to pack them as resources into the library.
Also added a "sweep" transition.
The TimeKeeper-based "smoothing" code still needs to be cleaned up, same with the threading stuff which never really worked.
Also removed the use of MilkdropPreset's PresetState class and add a class-specific copy shader.
This makes hard transitions a bit "smoother", as they won't always start from a black screen. Not really noticeable with fast presets, but some slow-warping ones will now gently dissolve the previous image.
This avoids two fullscreen draw calls during transitions, and should also be slightly faster than using glBlitFramebuffer(). As with all drawing operations, we currently don't really care about the target framebuffer size or aspect ratio and just draw a quad over the whole viewport.
43dbf9d to
9a73a88
Compare
Member
Author
|
Updated projectm-eval submodule to contain the yyerror function signature fix. |
Member
Author
|
Added a fix for blur textures. Was using the wrong input texture, and the blur textures weren't properly flipped to align with the main texture. |
blaquewithaq
approved these changes
Nov 16, 2023
…gher resolutions. Now we don't add the half texel offset to the vertex coordinates, but to the calculated u/v, which will prevent the texture wrapping (happens mostly with "nearest" interpolation lookups) mentioned in Milkdrop's code from happening, but make the mesh exactly fill the screen.
Member
Author
|
The last commits should also wrap up all known rendering issues, except for some preset shaders rendering blackness due to NaN/Inf values in the calculations. These aren't easy to fix (if at all), but not affecting too many presets. Will then merge this branch shortly. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
New Preset Transitions
This changeset implements a new transition method using fragment shaders to smoothly blend from one preset to another. Currently, there are six different, randomly chosen transitions, most having some varation to make the transitions less repetitive:
More shaders can be added quite easily. Documentation to write the shaders is available as a Gist here, will move it to the Wiki after merging the PR. I've implemented them in a way that makes it really easy to test them on Shadertoy and use them with minimal or even no changes in projectM.
Other Changes
While the main focus was implementing the transitions, a few other changes were done either to aid in the implementation or to improve smaller things which I've stumbled upon during the implementation and didn't find big enough to create a separate PR: