Create xr full screen effects doc page #10727
Conversation
devloglogan
added
enhancement
topic:xr
|
Personally i feel we shouldn't be talking about post processing here. Post processing effects suggest that you modify the rendered output and that is where the big no-no's come in. Vignettes' etc are not post processes. They are screen space effects that use a quad to render their output (actually a single triangle would be better but we don't have an easy primitive for that). So I think we need to come up with better naming. In the same line, I don't think that referencing the original post processing document is a good idea. Again, we just set people on the wrong footing, they will read that, figure out they can do that in XR as well, and then when they are too far along find out that doing so is what is causing their performance to never get up to spec. By then it's too late. |
|
@BastiaanOlij understood, and now that I understand the term a bit better I fully agree! @dsnopek had mentioned something similar to me elsewhere. I'll rework this soon to swap that term out for something like "full screen effects" and also remove the reference to the other doc. |
|
@devloglogan it does feel like nitpicking but I feel we can prevent ourselves a bit of hardship if we get that bit right :) |
devloglogan
force-pushed
the
asymmetrical-fov-doc
branch
from
5eacb0c to
8847300
Compare
devloglogan
changed the title
|
Alright, I've opted for "full screen effects" as the term instead and removed the reference to the other doc entirely (which adds a touch more on the basic full screen quad setup). |
| shader_type spatial; | ||
| render_mode depth_test_disabled, skip_vertex_transform, unshaded, cull_disabled; | ||
|
|
||
| void vertex() { | ||
| POSITION = vec4(VERTEX.xy, 1.0, 1.0); | ||
| } | ||
|
|
||
| void fragment() { | ||
| ALBEDO = vec3(0.0); | ||
| ALPHA = dot(UV * 2.0 - 1.0, UV * 2.0 - 1.0) * 2.0; | ||
| } |
There was a problem hiding this comment.
I'm not sure about including the incorrect shader code in full, because folks may not read very closely and just copy-paste this.
I think it may be better to only show full shader code for the correct one, and maybe put comments calling out the part that adjusts for the asymmetric projection matrix? Saying like, "if you remove this, the effect won't be correctly centered")
| Here is a simple vignette shader that you might apply to the quad, darkening the edges | ||
| of a user's screen: |
There was a problem hiding this comment.
If we're not linking to https://docs.godotengine.org/en/latest/tutorials/shaders/advanced_postprocessing.html, then I think we need to include some more information than this, explaining:
- The
MeshInstance3Dnode they need to add, the size of the quad mesh, and to put it as a child of the camera. Some of this is shown in the images, but I think we should have it in words too. - That we're making it full screen by setting the
POSITIONin the shader. (This ends up being implied in the "Applying the projection matrix" section, but I feel like it'd be best to state it up front)
| However, when creating an effect that is centered straight ahead in the user's view | ||
| (such as the above vignette effect), the end result may look incorrect in XR. |
There was a problem hiding this comment.
This is shown wonderfully in the picture, but I think we should also say in words, why it doesn't look correct in XR (that the center of the rendered output we are producing isn't necessarily the center of the user's view in XR, because our output will be deformed to match the lenses of the headset)
Also, I think it would also be cool to show a screenshot from inside the headset showing how the correct and incorrect versions look, in addition to the screenshots of the render target texture. Maybe it could be shown in a 2x2 grid, with the headset image above the render target image? Otherwise, it might not be entirely clear that the off-center effect on the render target is actually the correct one that will look centered in the headset
| Currently, full screen effects that require reading from the screen texture effectively disable all | ||
| rendering performance optimizations in XR. This is because, when reading from the screen texture, | ||
| Godot makes a full copy of the render buffer. Since this may create performance issues, it is recommended | ||
| that custom effects be limited to per-pixel ones such as the above vignette shader. |
There was a problem hiding this comment.
I think it could be made a little clearer that this limitation doesn't apply to the technique shown here. Having a "Limitations" section makes it sound like this is a limitation of what was shown above, rather than a limitation of a totally different way to approach doing this, which we didn't show :-)
devloglogan
force-pushed
the
asymmetrical-fov-doc
branch
from
8847300 to
68e234e
Compare
|
@dsnopek Thanks for the review! I believe I've addressed all of your suggestions, please take another look at the doc when you get a chance. :) |
Adds a doc page informing on how users can take asymmetric FOV into account in full screen quad
post-processingshaders.@BastiaanOlij mentioned that attempting to do this while reading from the screen texture is a big no-no so I also included a section at the bottom attempting to warn users about that.