ObjReader Community
WIP => WIP => Topic started by: Michael Lobko-Lobanovsky on June 11, 2019, 05:26:16 pm
-
I'll be damned!!! I got FXAA working!!!
(!!! No visible trace of extra GPU usage !!!)
8) 8) 8) 8)
-
Thumb up my friend!
-
Thank you, my friend!
I need time to tweak its parameters and incorporate it into the menu.
It looks a little poorer than the 32x MSAA to which we have already grown accustomed to but it comes at absolutely no cost for animated model+animated background combinations! And we can still keep MSAA switchable for crucial high quality renders, after all. :)
-
In an attempt to push the limits "beyond the horizon" and see how much overhead we really have, I've just run the whole thing at a custom resolution of 2560x1440 pixels on my main monitor.
Of course heavier shaders' usage went up to 100% but more reasonable shaders stayed within acceptable limits.
The screenies I took will give you a better idea of what FXAA is going to look like. As I said, its jaggies aren't perfectly smooth and transparencies look somewhat heavier but overall, the setup seems perfectly usable to me for less demanding animated scenes.
Note that the Serenity model has over 4Mo polies and several animated meshes! :)
-
Yes, antialias looks less smoother to what i am accustomed to.
And for transparency, i shall have to see it on my computer(s) before i could make a reliable comment.
If this FXAA is going to be an extra global #meta (and menu) parameter that is fine to me ;)
-
Yes, we're going to have 3 new global #metas regarding AA: #msaa (default), #fxaa, and #csaa (disabled on non-nVidia platforms) probably each followed by one of four parameters off, min, good, or max to denote the respective AA technique and its level for a given model.
Technically, we won't even keep the Use framebuffers toggle in the menu. If the user's OpenGL driver supports FBO, then their main viewport will stay simple (aliased) at all times and Mobj_choosePixelFormat() will be bypassed altogether. All MSAA/FXAA/CSAA adjustments (min=4x, good=8x, max=driver-dependent 16x or 32x -- in terms of MSAA) will be done fast and simple at the moment the FBOs are re-created on window resize. If the driver doesn't support FBOs at all, which is quite unlikely these days, then all AA bells and whistles will be disabled and the main viewport will be created through Mobj_choosePixelFormat() as usual at its maximum MSAA setting possible, and only an ordinary AA on/off option will be accessible through the OpenGL API glDisable/glEnable(GL_MULTISAMPLE). 8)
-
OK, that sounds good to me!
-
Well, my here's my progress:
1. I was able to make out what was wrong with Serenity jet transparencies in the hi-res screenie I posted earlier. The cause was a bad choice of d value in the model's cone material. The value was less than that of jet material. But the cones are always farther behind the jets from the observer's point of view and therefore they should be always drawn the first!
To this end, the cone's d should be at least a tad larger than the jet's d. See the topmost screenshot for d adjusted from 0.52 (yours) to 0.7 (mine).
2. To calc the borders that should be anti-aliased, the original FXAA shader uses, evidently for speed reasons, an approximate luma parameter that's tied to the pixel green channel value. I changed that approximation to an exact, classic luma calc that improved the AA quality dramatically -- again practically at no GPU usage cost despite about a dozen additional square roots now being used for each screen pixel.
Default FXAA is now almost as good as 32x MSAA with the only exception of borders whose on-screen inclination angle is very close to a multiple of 45o except near-horizontal and near-vertical ones that are still anti-aliased all right. See the middle screenshot to compare FXAA against MSAA.
3. As I said, despite the substantial extra square root calc in the shader, the overall impact of FXAA on the GPU is close to nil. See the bottommost screenshot to compare CPU/GPU usages at 30FPS for hi-res non-AA and FXAA renders of Serenity against an animated background shader. 8)
______________________________________________
The last but not the least issue I have yet to cope with, is proper mesh texture mipmapping that seems to be at fault when rendered into a non-MSAA FBO...
-
Thank you for the progress report!
-
Patrice,
Technically speaking, the FXAA shader is just another, albeit rather verbose, full-screen post-processing shader like Sepia, Brightness/Contrast and others.
So, my question is:- Do we arrange the three anti-aliasing modes (MSAA, CSAA, FXAA) in a mutually exclusive 3-state toggle in their own Anti-aliasing... submenu; or
- Do we keep FXAA in the ordinary Fancy submenu with the other PP shaders, thus making it effectively applicable on top of MSAA or CSAA if only both of them haven't been explicitly switched off in their own submenu? ;D
-
Do we arrange the three anti-aliasing modes (MSAA, CSAA, FXAA) in a mutually exclusive 3-state toggle in their own Anti-aliasing... submenu
Yes, that would be more intuitive.
The menu "View"-->"Render mode control" --> "Design mode"/"Fancy mode" has been superseded by the "Inspect" and "Render" popup menu.
Don't you think that we could get rid of duplication?
-
I think we shouldn't be using the View menu as our system (right-click) popup at all because it leads to inevitable duplication of the items in the main menu.
Apart from populating the main menu's popups with unique elements grouped logically into File/View/Inspect/Edit/... trees, we should create a dedicated popup menu that will be used exclusively for system RMB double-clicking in the viewport. It should reuse a selection of elements from the main menu in some other general layout that will be most appropriate for use in the full-screen mode.
This will make the View popup lighter and devoid of duplicates with the other popups, and it will make the system popup completely independent of main menu. It can then be made as full of features as we want and I can even move my custom arrangement into my own MLL_DEV.h altogether for conditional compilation.