HDR Pipeline

From FlightGear wiki
Jump to navigation Jump to search

1rightarrow.png See Compositor for the main article about this subject.

Caution  The feature discussed below is currently considered experimental, i.e. must be considered proof-of-concept for the time being. Fernando does not provide any guarantees whatsoever about if or when the HDR pipeline will be "production-ready" though, so the recommendation for aircraft devs willing to update their 3D models would be to wait for a bit (to the end of the year or when 2021.x comes out) to see if it's worth the effort.[1] It's just to showcase what's being worked on. If you'd like to learn more, please get in touch via the developers mailing list.
HDR Pipeline
Started in 04/2021 (early proof-of-concept)
Contributor(s) Fernando García Liñán [2]
Changelog https://sourceforge.net/u/fgarlin/profile/feed.rss

Unfortunately trying to load any scenery crashes FG instantly. Isuspect it's due to the core/compatibility profile issues I describedearlier.[3]
This article is a stub. You can help the wiki by expanding it.


After getting convinced to pursue this by some of the core devs, for the past couple of days Fernando has been working on a new Compositor pipeline. It's still very much experimental (trying to load any scenery crashes FG!), but it's somewhat working under very special circumstances.

This is currently using the most popular PBR model for real time applications. This particular BRDF has also been recommended by the glTF spec, so it shouldn't be too bad. :) See https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md#appendix-b-brdf-implementation


Last updated: 04/2021

Fernando's long term project from now on will be the "HDR" pipeline, which will be strictly OpenGL 4.2 compatible.[4]

Since everything on this pipeline relies on the core profile, I'm basically waiting for the move to happen so I can do the depth reversal trick.[5]

Again, this is all *very* experimental for now. A lot of things are broken because I'm forcing the use of core profile shaders (thanks Nvidia for letting me do this under a compatibility profile context!), so this is nowhere near usable. Still, I'm planning to release this to next in the next week or so because it doesn't break anything: everything is in FGData and on a different compositor pipeline, so Classic and the C++ core are completely unaffected. In general the move to the core profile will probably fix a lot of the issues that this pipeline currently has.[6]


For now, the main goal is definitely increasing motivation to get on with moving to Core profile.[7]


No compute shaders required, so Mac should work fine as long as we are using at least GL 3.3. :) [8]


Most 3D artists nowadays are fairly familiar with PBR content creation tools. I think using PBR and trying to abstract the 3D artist from the "under the hood" stuff like Effects, XML definitions, etc. will always be a good step towards lowering the entry barrier for content creation in FG. Of course these developers will have to learn how animations, systems, FDMs, Nasal, etc. work, but streamlining the 3D part to a simple "Export to glTF" button will be key in my opinion.[9]


glTF will only prove beneficial for PBR-based models. Otherwise I think we should be fine with the current model-combined approach since aircraft devs are already familiar with this workflow. The HDR pipeline will only work on 2021.x because it requires the core profile, so I think it makes sense to only offer support for glTF on 2021.x to avoid compatibility messes.[10]


Fernando recommends that aircraft devs don't try to support this because it's still very experimental, so they might be working on something that is subject to change. Of course if they just want to play around feel free to ask for help.[11]


For now I plan to only support WS30. I'm not sure how the materials are going to work for the terrain, but I guess it's too early for now (both for WS30 and the HDR pipeline!).

The real time environment reflection pass renders the skydome and the terrain, so I'd be really useful to have some way of setting the WS30 LOD level from the Compositor/Effects. That way we can use a really rough terrain that renders very fast. The difference in quality shouldn't be too noticeable as we are rendering to a small 128x128 cubemap.[12]

Implementation Details

A few implementation details for the curious:

  • It's a deferred renderer. Most post-processing effects integrate very nicely with a deferred pipeline, and modern forward rendering techniques usually require a depth prepass. I haven't found an easy way to share culling results between passes in OSG so that the main forward pass reuses the culling information gathered during the depth prepass, so I preferred to just go deferred.
  • Entirely PBR-based. Old/legacy materials try to "translate" from the legacy ambient/diffuse/specular model to PBR metalness/roughness. Still, the classic pipeline isn't going anywhere. If a particular aircraft is very broken under this pipeline, the user is free to use ALS/classic.
  • HDR and eye adaptation. Lighting values are written to HDR buffers and then tone mapped based on a exposure setting. This exposure parameter is calculated automatically based on the average scene luminance (like a camera on the Auto setting would do), but there is the possibility of lowering/increasing the exposure manually if the user feels like the scene is too bright/dark. Maybe the pilot is wearing sunglasses? :)
  • Real time environment mapping. At the start of the frame we render to a cubemap and subsequent passes use this information to evaluate indirect lighting.
  • Miscellaneous post-processing passes like ambient occlusions, FXAA,bloom, etc.



For now, the initial plan is to only support PBR through glTF models, and glTF does support using numerical values for the whole material instead of a texture.[14]


Note  we need to upload the screen shots to the wiki so that we can reuse these for the newsletter/changelog respectively

Here are some screenshots of the c172p on the Nimitz. Aircraft carriers are a nice substitute to actual terrain :)

A few more screenshots

Known Issues

Unfortunately trying to load any scenery crashes FG instantly. I suspect it's due to the core/compatibility profile issues I described earlier.[15]

Mac only supports up to OpenGL 4.1, which doesn't have compute shaders. Compute functionality is only accessible through Metal (or MoltenVK as you mentioned).

The advantages to compute shaders are many, but again we can't use them easily. In an ideal world Mac offers proper support for OpenGL and we don't have to even switch to VulkanSceneGraph, but that's not the case unfortunately. [16]