Replies: 1 comment
-
Somewhat related - a short list of postprocessors that might be interesting in the future:
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This will be very GLMakie focused since I thought about this in that context.
Current Situation
Currently every plot ends up in a big
renderlist
inScreen
. During rendering they all go through the same steps:Makie.rvalue2d
ssao = true
andtransparency = false
ssao = false
andtransparency = false
transparency = true
The postprocessors are also collected in a list, however this list is static in some sense. I.e. the first element is SSAO or a placeholder, the second OIT, the third FXAA or a placeholder, the fourth copy-to-screen. Whether a placeholder or the respective postprocessor is used depends on the global variables
enable_SSAO
andenable_FXAA
. This whole setup is a result of SSAO eating a lot of vram and some users having issues because of it.Problems
One big problem is the lack of customization. This comes up in a bunch of different ways. First, as already mentioned above, we lack a clean way to adjust what postprocessers run and which don't. Some postprocessors, like SSAO, shadow mapping or lighting (if done via deferred rendering) are just unnecessary for 2d plots. But they would still be nice to have for 3D. Similarly OIT and fxaa are probably unnecessary for UI components (lines, text and scatter have their own antialiasing).
We also don't have a clean way to adjust things specific to a postprocesor. For example, SSAO currently has settings for
bias
,radius
andblur
range. CurrentlyScene
has attributes for these settings and SSAO runs once per scene in case these attributes are different between them.The system of having attributes like
fxaa
,ssao
andtransparency
for each plot also makes adding new postprocessors rather annoying. Every new postprocessor adds 2x more combinations, many of which can't be resolved without adding at least another intermediate buffer. For example the combination ofssao = true
andtransparency = true
currently just ignores ssao.Redesign
I think a good reference for a redesign is Blenders node system. From my limited understanding each node more or less represents a shader and you can connect inputs, outputs and settings between them.
In analogy to that each postprocessor could be represented by some
Postprocessor
type with connected inputs and outputs. I think settings (i.e. uniforms) are probably better of as Observables. A collection of postprocessers would make up a renderpass, which would be part of a Scene. I'm hoping it's possible to handle a lot of the details in backends. (E.g. creating and reusing buffers, getting shaders, OpenGL setup, etc)I think for plots it would make sense if they could specify at which point during the renderpass they render. I.e. we could have a loop like this
on the backend side and filter plots based on
stage
. It's probably not too hard to allowstage
to be the name of a postprocessor either. So you could havescatter(... stage = :fxaa)
, for example, to render just before the FXAA postprocessor runs.To avoid running the same renderpass over and over, it would be good if multiple scenes could use the same one. I think in most cases it's enough if a scene could refer to its parent. (Lots of MakieLayout components create their own subscenes from figure.scene and could be combined like this. A case like
px_scene > 3D_scene > px_scene
would result in 3 separate render passes. This might also be useful for making an overlay scene.) On the backend side it might be useful to give each backend renderpass it's own renderlist for this.Beta Was this translation helpful? Give feedback.
All reactions