Multiple post shaders support.#6719
Closed
Aviu00 wants to merge 1 commit into
Closed
Conversation
Author
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.
Closes #5105
Adds support for multiple post shaders per sprite. This will cause breaking changes, content pr will follow when this one leaves draft state.
This is almost finished (not entirely), but review would be appreciated. Note that I had to do some weird tricks to make this work.
It works by creating 2 render targets with same size per sprite (currently it caches all render targets. TODO smaller sprites should reuse rt crated for larger sprites). It draws sprite contents on first rt, then loops through all shader instances, copying rt contents to intermediate rt, then clearing first rt and drawing intermediate rt contents onto it with shader applied.
Before there was a trick to offset the viewport while rendering sprite to make sure lighting application works, this new implementation does the same thing but with multiple render targets and ping pong rendering this leads to some issues: We are drawing shaders from small rt onto small rt, before we were drawing shaders from small rt onto large viewport. This means before we used normal viewport when drawing shaders, now we are using offseted viewport. This leads to fragcoord being offseted for shaders, I fixed it by manually offseting it back by creating new FragCoordOffset uniform for base fragment shader.
Another problem is lighting application. It (1) renders light/shadows over and over on each shader iteration, and (2) renders shadows again when drawing from rt onto viewport. It is fixed by 1: overriding shader blend mode to None, 2: disabling lightingReady temporarily (see my comments in the code)
Post shaders are stored in SortedDictionary<SpriteShaderKey, SpriteShaderData>. It is sorted by shader render order defined in shaderkey and hashed by unique id stored in shaderkey. This can be yamlable, see media. TODO allow yaml to specify id for key (currently it always generates random one form yaml) so that entsys can access it if needed.
Also made BeforePostShaderRenderEvent byref
Media
Outline + water transparency shaders:
Some more showcase with 3 custom shaders + outline, different render order defined in yaml:
shaders.mp4