Board index FlightGear Development Effects and shaders

The Compositor

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: The Compositor

Postby Thorsten » Tue Dec 31, 2019 8:04 am

The shader lookup is not automatic.


It doesn't seem an outrageous problem to construct the correct search path. I certainly have not specified 'Compositor' as part of the search path aircraft-side - so the aircraft-side search path already gets 'Compositor' appended - what is the problem in making it append 'ALS' or 'default' or whatever dependent on what pipeline is running?

I'm sorry, maybe I'm overlooking something, but it seems the kind of problem solvable in half an hour - compared to manually converting a gazillion of aircraft, that's a very good bang for the buck.

Could you elaborate why this can't be made to work automatically?

The flickering is what it is, it's inherent to shadow maps. I even implemented shadow map stabilization, but it only works for non-moving objects. Again, try bigger resolutions, and if that doesn't work just disable them. I don't think the flickering is that bad. I don't even notice it unless I pay attention to it.


Just to clarify - the flickering of the internal shadows is tolerable - given that we should have kept support for opacity maps and that opacity maps do not flicker, I believe that problem is under control.

The flickering of low vegetation and vegetation shadows however is two orders of magnitude worse - the z-fighting is a really big problem (for me at least). And yes, it is that bad under some conditions - try dense shrubland in Hawaii (it's less in effect for tall trees though) - I really got dizzy and developed a headache after 20 minutes - I am somewhat sensitive to these things, so it won't affect everyone the same way, but I wouldn't be able to use FG any more if it would stay that way.
Thorsten
 
Posts: 11580
Joined: Mon Nov 02, 2009 8:33 am

Re: The Compositor

Postby Icecode GL » Tue Dec 31, 2019 10:58 am

Could you elaborate why this can't be made to work automatically?


Because I don't think it's a good idea. Less flexibility, no shader reusage between pipelines... and automatic pathing is not intuitive and can get really confusing, specially when you edit the middle of the path (i.e. you don't add stuff just at the beginning or the end). All to avoid porting aircrafts with custom techniques and shaders to the Compositor... which you'll have to do anyway because a) techniques numbering has been changed and b) effect schemes have been introduced.

so the aircraft-side search path already gets 'Compositor' appended


That's completely different. Adding 'Compositor' is temporary. And, as trivial as it might sound, this isn't short of its own problems as well. For example, relative pathing for Effects in model XMLs has stopped working because of this, and won't work until I remove the Compositor prefix.

compared to manually converting a gazillion of aircraft, that's a very good bang for the buck.


I think I can count the number of aircrafts using custom techniques and shaders with my fingers...

I am somewhat sensitive to these things, so it won't affect everyone the same way, but I wouldn't be able to use FG any more if it would stay that way.


Try disabling vegetation or decreasing the depth range by adding <z-far>10000</z-far> in the 'forward' pass in the ALS pipeline.
Icecode GL
 
Posts: 610
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: The Compositor

Postby Thorsten » Tue Dec 31, 2019 11:27 am

Less flexibility, no shader reusage between pipelines... and automatic pathing is not intuitive and can get really confusing, specially when you edit the middle of the path (i.e. you don't add stuff just at the beginning or the end). All to avoid porting aircrafts with custom techniques and shaders to the Compositor...


Well, yes - how do you expect we treat regression testing if we can't run the same aircraft on two FG versions any more? This is rapidly developing into a maintenance nightmare for me, sorry.

Let me state this again (I'm sure I've emphasized that point before) - one really important goal that will greatly enhance acceptance by the community all over the place is that things continue to run smoothly without the need to intervene aircraft-side - only using new features should require intervention aircraft-side.

Yes, I understand the urge to switch to a clean new system of handling things. But it has never really worked. The community will not step up and do the work, most people will curse you for the additional work you impose on them, some will have left and broken aircraft will lie around. The most important goal - far more important than a clean system - is to have a smooth migration. Look at the history of Rembrandt - it required too much work by everyone else to really gain traction and died off.

I don't know what exactly you mean by 'custom techniques and shaders' - most aircraft which use effects inherit from a pre-defined effect which used to reside in FGData/Effects/ - and there's a substantial number of them. Using GLSL code that resides aircraft-side is discouraged unless there's a specific reason.

But the lookup problem is - anything with Aircraft in front of the path

Aircraft/SpaceShuttle/Models/Effects/Interior/shuttle-interior

should reference the path 'as is' because it is clearly aircraft-side.

Anything with Effects/ in front of the path

needs to be patched to the currently active pipeline effects folder, and likewise anything with Shaders/ in front of the path needs to be patched to the currently active pipeline shader folder.

That's the price to pay for separating techniques into subfolders according to pipeline. I don't see how a different lookup scheme could work without creating a royal mess.

For example, relative pathing for Effects in model XMLs has stopped working because of this, and won't work until I remove the Compositor prefix.


Well, we should be able to try several path variants to locate the intended file rather than blindly add strings to the path.
Thorsten
 
Posts: 11580
Joined: Mon Nov 02, 2009 8:33 am

Re: The Compositor

Postby Icecode GL » Tue Dec 31, 2019 11:44 am

Let me state this again (I'm sure I've emphasized that point before) - one really important goal that will greatly enhance acceptance by the community all over the place is that things continue to run smoothly without the need to intervene aircraft-side - only using new features should require intervention aircraft-side.


Repeating yourself won't make your points more valid. :)

Using GLSL code that resides aircraft-side is discouraged unless there's a specific reason.


Then why are you complaining about aircraft-side custom shaders? If you don't create your own techniques and your own shaders in the aircraft you should be fine...

Anything with Effects/ in front of the path
needs to be patched to the currently active pipeline effects folder,


Relative pathing exists and some aircraft devs use it extensively. For example, 'Effects/fuselage' can mean 'Aircraft/c172p/Models/Effects/fuselage' or '$FGDATA/Effects/fuselage'.

Well, we should be able to try several path variants to locate the intended file rather than blindly add stuff.


Really? I'd like to see you do it if it's so trivial.


I'm not wasting time explaining things I already know and that I've taken time to investigate. If you think you have a better plan, by all means go ahead and implement it. If you don't want to implement anything please just review the clustered shading if you want/have the time. If not I'll try to find someone else who will.
Icecode GL
 
Posts: 610
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: The Compositor

Postby Thorsten » Tue Dec 31, 2019 2:22 pm

Repeating yourself won't make your points more valid.


Okay, I'll cut this short now, as I don't want to do overly much FG today. I was under the impression that we had reached an agreement with regard to the backward compatibility. Reading this answer, I feel personally let down and deceived by you here and I am... I dunno - sad and annoyed at the same time that this front needs opening again.

So be it - I guess this means in the new year we'll have meet for a new series of discussions on how to proceed per PN - I want to see this succeed, I've seen plenty of things fail in the FG cosmos and I have an inkling how and when failure happens. In the event - getting your supporters sad and annoyed generally isn't a good strategy, neither is people trying their favorite airplane for the first time and seeing its rendering broken. Group dynamics is - for better or worse - an important part of what makes things a success.

I'm not wasting time explaining things I already know and that I've taken time to investigate


Making me understand is part of a contribution review process though... I ask for explanations because obviously I do not know.

Then why are you complaining about aircraft-side custom shaders


I am not - I am complaining about the path lookup - the file exists, the lookup path is already changed - it's just not changed to the right location.
Thorsten
 
Posts: 11580
Joined: Mon Nov 02, 2009 8:33 am

Re: The Compositor

Postby Icecode GL » Tue Dec 31, 2019 2:48 pm

I really don't know why you are over complicating things. I've explained to you why the errors you have noticed exist and what I plan to do about them. You don't need this information to review the merge request, but I took the time anyway because I felt you deserved any explanation I could provide. If, however, you lecture me on "group dynamics" and you decide to point out how trivial implementing any of those "features" is, even though you lack the necessary background to provide proper solutions to these problems... Well, I apologize if I sounded rude, but you sounded a bit rude to me as well.
Icecode GL
 
Posts: 610
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: The Compositor

Postby wlbragg » Tue Dec 31, 2019 7:04 pm

wlbragg wrote in Mon Dec 30, 2019 5:17 pm:
* interior shadows are (like with Rembrandt) too flickery for my taste - unfortunately flickering is something I do not tolerate well, it (literally) gives me headaches

I'm not sure what your seeing for interior shadows, unless you did some specific porting. As far as I was aware, and was told, interior shadows are not ported yet.

A 4096x4096 shadow map - if the surface isn't 'special', you see that as interior shadow, and while it works fine outside the aircraft, from close-up it's very flickery.

Shadow maps in the Compositor have been designed to work with any light source (yes, even a point light).

Is there anywhere that documents the implementation of "interior shadow" maps for the compositor. I'm in the dark here as to how to implement it (details) and would really like to work with it. Interior shadows are by far one of my biggest incentive for using and testing compositor.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 5452
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: The Compositor

Postby Icecode GL » Tue Dec 31, 2019 7:43 pm

Make sure your interior models don't use the model-interior Effect. They should cast/receive shadows then.
Icecode GL
 
Posts: 610
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: The Compositor

Postby Hooray » Thu Jan 02, 2020 1:11 pm

FWIW, I do think Thorsten's point is valid, i.e. I remember we talked about lowering the barrier to entry to ensure that people can "tinker" (experiment) with the compositor - there are numerous examples of projects where some key contributor decided to delegate the grunt work to middleware developers, and basically most of the efforts failed somewhere along the road.

We kinda had the same discussion, when we talked about coming up with a dedicated build mode, and with a way to enable/disable any compositor related functionality at build time, but also to work towards an implementation where toggling the compositor on/off during startup might become an option sooner or later, and I believe a number of core devs even went further by tossing around the idea of dynamically switch the compositor on/off at runtime.

The point being, I don't have anything specific to contribute at this point, beyond suggesting that Thorsten's point is indeed valid, and it's been proven over and over again.

I think this is actually exemplified by our talks of having a dedicated compositor binary vs. integrating this functionality directly inside the fgfs binary, and how a number of core developers subsequently made the same points in the aftermath of our original talks, and Richard's PDF file detailing a dedicated directory structure for each pipeline is another good example actually.

Then again, I don't think there is any need for harsh language here, I believe it is obvious that Thorsten is highly interested in the functionality, and that you are highly interested in seeing Thorsten being able to use the compositor-enabled binary and actually experiment with it, so pain/gain is out of the question here - the point is finding the LCD and then take it from there.

Anyway, my 2c - and no offense intended or taken, feel free to get in touch if you think there is anything I can do to help make a point - otherwise, happy new year to everyone :-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11738
Joined: Tue Mar 25, 2008 8:40 am

Re: The Compositor

Postby amue » Sat Mar 07, 2020 10:26 am

Regarding the z-fighting/flickering issue:
Icecode GL wrote in Tue Dec 31, 2019 10:58 am:Try disabling vegetation or decreasing the depth range by adding <z-far>10000</z-far> in the 'forward' pass in the ALS pipeline.

Would it be possible to define a near/far camera pair (similar to the legacy pipeline) in the 'forward' pass in the ALS pipeline?
I really like the shadow in the Compositor/ALS pipeline, but the z-fighting/flickering issue is a big problem for me too.
amue
 
Posts: 41
Joined: Tue Apr 03, 2018 9:13 am

Re: The Compositor

Postby Icecode GL » Tue Mar 10, 2020 10:39 pm

It has been tried before, yes, but was removed in favor of a reversed Z-buffer. Having multiple cameras doesn't play well with shadow mapping and multipass in general.
Icecode GL
 
Posts: 610
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: The Compositor

Postby amue » Tue Mar 10, 2020 11:22 pm

Icecode GL wrote in Tue Mar 10, 2020 10:39 pm:It has been tried before, yes, but was removed in favor of a reversed Z-buffer. Having multiple cameras doesn't play well with shadow mapping and multipass in general.

Yes, I already ditched the near/far camera approach.
Currently I'm using the logarithmic depth buffer approach: https://outerra.blogspot.com/2013/07/logarithmic-depth-buffer-optimizations.html. By changing the vertex and fragment shaders I got rid of the z-fighting. But my framerate dropped a little bit (from 44 fps to 40 fps on my GTX 670).
amue
 
Posts: 41
Joined: Tue Apr 03, 2018 9:13 am

Re: The Compositor

Postby Icecode GL » Tue Mar 10, 2020 11:28 pm

Interesting. Did you change every fragment shader to output to gl_FragDepth directly? Or was it something more sophisticated on the C++ side?
Icecode GL
 
Posts: 610
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: The Compositor

Postby amue » Wed Mar 11, 2020 8:13 am

Icecode GL wrote in Tue Mar 10, 2020 11:28 pm:Interesting. Did you change every fragment shader to output to gl_FragDepth directly? Or was it something more sophisticated on the C++ side?

I only changed the shaders.

In the vertex shaders I output the varying float flogz:
Code: Select all
flogz = 1.0 + gl_Position.w;

In the fragment shaders the varying flogz is used for computing and setting gl_FragDepth:
Code: Select all
gl_FragDepth = log2(flogz) * Fcoef_half;
with
Code: Select all
Fcoef_half = 1.0 / log2(farplane + 1.0);

In my case Fcoef_half is a constant with farplane = 100000.0. The author of the linked article also suggest to input Fcoef_half as uniform. In this case farplane can be configured at runtime.

I also tested the vertex shader only variant by writing to gl_Position.z:
Code: Select all
gl_Position.z = (log2(max(1e-6, 1.0 + gl_Position.w)) * Fcoef - 1.0) * gl_Position.w;

(Note: In the linked article the author forgot to multiply with gl_Position.w)
But with the vertex shader only solution I got clipping issues with the terrain when I was on the runway or flying very low.
amue
 
Posts: 41
Joined: Tue Apr 03, 2018 9:13 am

Re: The Compositor

Postby vnts » Thu Mar 12, 2020 10:25 am

The compositor & screens in this thread so far of the Carrier, Aircrane, clouds etc. looks awesome :mrgreen: :mrgreen:

amue wrote in Tue Mar 10, 2020 11:22 pm:Currently I'm using the logarithmic depth buffer approach: https://outerra.blogspot.com/2013/07/logarithmic-depth-buffer-optimizations.html. By changing the vertex and fragment shaders I got rid of the z-fighting.
But my framerate dropped a little bit (from 44 fps to 40 fps on my GTX 670).

44 to 40 FPS drop is 9%. Assuming your system was fragment (or vertex?) shader bound in that scene so the slightest increase in load reduced FPS. That sounds high for a simple expression or two add to shaders(?). As the outerra article suggested maybe there was significant overdraw in the scene you tested (and it violated an assumption needed for an optimisation, like not having wait for the fragment shader to finish before depth testing). If that scene wasn't the worst case of overdraw in FG with the compositor&ALS, there may be bigger FPS drops elsewhere (?).
Icecode GL wrote in Tue Mar 10, 2020 10:39 pm:..in favor of a reversed Z-buffer. Having multiple cameras doesn't play well with shadow mapping and multipass in general.

So, for a hypothetical custom shader based z-buffer formula..

AIUI Ultimately there's a limited number of depth levels ( 2^(16/24/32? z-buffer bit depth depending on age of GPU?) ) and it's up-to FG to assign them.

Wondering: With a logarithmic z-buffer there will be fewer levels far away. Wondering what might a hypothetical issue look like.. Any possible issues would arise is if there's a scene with large draw distances, and things with different colours. Like the bare terrain mesh and any other geometry on top of it. If the log function & Fcoeff tuning is doesn't assign enough levels to keep things separate, geometry close together might show wrong or slowly fluctuate colours on approach until the camera is close. With a larger LoD rough range: if there's a city on a slope parts of the buildings could be partially buried by terrain until the camera gets close (?). Buildings might pop out from the ground. If there are trees of different colours close together, like evergreen species and deciduous autumn leaves a forest might noticeably change colours as the camera approaches the forest. Just a guess at what an issue might like, hypothetically. Maybe worse on old GPUs. If(!) something like this turns out to be a concern, it might need a different tuning formula for Fcoeff based on the scene, or just piecing together 3 separate functions for near/middle/far based on the particulars of the scene.
Icecode GL wrote in Tue Mar 10, 2020 10:39 pm:multipass

If it's still possible to draw the near cockpit model in a separate pass, it would allow cockpit to be drawn with better resolution, better texture filtering settings, so it's crisp and readable compared to the the environment. This may be the biggest & most effective performance tweak. As I mentioned in the Anti-aliasing wiki page (link), the trend AIUI in LCDs is to divide the screen to smaller pixels, and people might already be running at too high a resolution for older GPUs.

The environment could be drawn at a specified fraction of the resolution, and with lower AA. Maybe (?) the external cockpit views, or airport structures people get close to, may need to be drawn at a higher resolution or with better AA compared to environment. If transparency AA could be set separately for overlays & grass in particular, it might let more people run overlays.

Kind regards
vnts
 
Posts: 152
Joined: Thu Apr 02, 2015 12:29 am

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 2 guests