Jump to: navigation, search

Project Rembrandt

16,750 bytes added, 15:01, 17 February 2019
Status (07/2014): obsolete due to Compositor
{{WIP}}== Why this the name ? ==[{{Wikipedia|Rembrandt Rembrandt] }} was a dutch painter living in the 17th century, famous as one of the master of [ {{Wikipedia|chiaroscuro]}}.
This project is about changing the way [[FlightGear]] renders lights, [[shadows]] and shades, and aims at making Rembrandt painting style possible in FG.
{{forum|47|Effects & Shaders}}
== What is it ? ==
|Deferred {{=}} rendering a geometry pass into the geometry (g-)buffer which holds positions, normals, materials, then doing all operations (texel, light, ...) in fragment passes on that buffer (or any others).<br/>
Forward {{=}} (usually) rendering part of the shading (typically ambient and diffuse light) per vertex, extrapolate all quantities which are declared as varying across triangles and hand them via rasterizer to the fragment shader which does the rest
|{{cite web |url=
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki>
|date=<nowiki>Sun Oct 19</nowiki>
The idea driving the project is to implement [ deferred rendering] inside FlightGear.
From the beginning FlightGear had a forward renderer that tries to render all properties of an object in one pass (shading, lighting, fog, ...), making it difficult to render more sophisticated shading
In FG, we end the rendering pipeline by displaying the [[Menubar|GUI]] and the [[HUD]].
All these stages are more precisely described if in this [ tutorial] that is the basis of the current code, with some addition and modifications. C++ developers interested in learning more about how Rembrandt works, will want to look at these initial $FG_SRC commits (note that the viewer related sources are now to be found in $FG_SRC/Viewer):* 94e3ae4c675463c358071e1d9da8de583cf56e15 * 6b008126b5fd99c38778c6293c15f9721a4fa509* 64e3e98069fb2310311687b9f099b338b8b375a5* bb16463d631a8d87310a54a573966eb1cca813e6
== Caveats ==
Deferred rendering is not able to display transparency. For the moment, clouds are renderer rendered separately and should be lit and shaded by their own. Transparent surfaces are alpha-tested and not blended. They would have to be drawn in their own bin over the composited image.
It also dondoesn't fit with depth partitioning because the depth buffer should be kept to retain the view space position, so for the moment, z-fighting is quite visible. Depth partitioning with non overlapping depth range might be the solution and should be experimented at one point.
The glow pass can make certain MFD MFDs (that use emissive color) unreadable because blurredof blurring. Should be treated as transparent.
== Implementation ==
<syntaxhighlight lang="xml">
<map-size type="int">8192</map-size>
And put 4096 or 2048 instead.
You can also use a startup parameter: <code>--prop:/sim/rendering/shadows/map-size=2048</code>
=== Configurable pipeline ===
The Rembrandt renderer uses an XML file to setup its pipeline for each viewport described in the camera group. This file describes the way the intermediary buffers are setup and how the different rendering stages are sequenced. The general outline of a pipeline file is as follow :
Each effect attached to the fullscreen passes define the way blending is done between the pass and the previous accumulation of render.
=== C++ implementation ===
On the C++ side, Rembrandt is set up in those steps:
* ''buildRenderingPipeline()'' is the last common function between forward rendering and deferred rendering. That's the point of start for specific deferred stuff. In this function we call ''buildDeferredPipeline()''
** ''buildDeferredPipeline()'' is just a wrapper for ''buildCameraFromRenderingPipeline()''
*** ''buildCameraFromRenderingPipeline()'' is where we initialize all buffers and create all the stages found in ''Effects/default-pipeline.xml'' with the call to ''buildBuffers()'' and ''buildStage()''
**** ''buildBuffers()'' is where we ask to build each buffer with the call to ''buildDeferredBuffer()''
***** ''buildDeferredBuffer()'' create a 2D texture
**** ''buildStage()'' is where we ask to build each camera depending on the type of the stage (geometry, lighting, shadow, fullscreen, display) with the call to ''buildDeferred*Camera()'' (where * is the stage type)
***** ''buildDeferred*Camera()''is where we build the camera, for each camera we attach the required buffers with the call to ''buildAttachments()''.
****** ''buildDeferredGeometryCamera()'' c.f [ What is it ?]
****** ''buildDeferredShadowCamera()'' c.f [ What is it ?]
****** ''buildDeferredLightingCamera()'' Only for the lighting camera (''buildDeferredLightingCamera()'') we have to build passes who is called with ''buildPass()'' c.f [ What is it ?]
****** ''buildDeferredFullscreenCamera()'' c.f [ What is it ?]
****** ''buildDeferredDisplayCamera()'' c.f [ What is it ?]
== Running Flightgear with Rembrandt ==
The Rembrandt renderer is now integrated in the main repository but needs to be enabled to run. There are two ways to enable it (only one is needed!):
* <code>--enable-rembrandt</code> (when using [[FGRun]], you may add this behind the <tt>FG_EXECUTABLE</tt> on the first page).
* <code>--prop:/sim/rendering/rembrandt/enabled=true</code> (with FGRun this can be added via <tt>Advanced > Properties</tt> on the last page, but only the <code>/sim/rendering/rembrandt/enabled=true</code> part).
The <tt>View > Rendering Options > Rembrandt Options</tt> dialog allows you to toggle and adjust the various features that Rembrandt offers.
Warning: RenderStage::runCameraSetUp(State&) Pbuffer does not support multiple color outputs.
Some card also exhibit The ssao effect provided in v2.8.0 may generate these messages like , more often on Mac : <pre>FRAGMENT glCompileShader "/Users/xxxx/Desktop/" FAILEDFRAGMENT Shader "/Users/xxxx/Desktop/" infolog:ERROR: 0:20: 'array of 2-component vector of float' : constructor not supported for typeERROR: 0:20: 'array of 2-component vector of float' : no matching overloaded function foundERROR: 0:20: 'const 2-component vector of float' : cannot declare arrays of this typeERROR: 0:20: 'v' : redefinitionERROR: 0:55: 'reflect' : no matching overloaded function foundERROR: 0:55: '=' : cannot convert from 'float' to '2-component vector of float'
glLinkProgram "" FAILED Program "" infolog: Fragment infoERROR: One or more attached shaders not successfully compiled -------------</pre> 0(37) : error C6013: Only arrays of texcoords may be indexed in this profileIn that case, and only disable ambient occlusion with a loop index variable 0(36) the command : error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable 0(35) <tt>--prop: error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable 0(34) : error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable/sim/rendering/rembrandt/ambient-occlusion-buffers=false</tt>
There is a number of additional options that can help to avoid these problems :
|Avoid the "error C6013" message on old cards at the cost of resolution in the cockpit. Set <tt>/sim/rendering/shadows/cascade-far-m[0]</tt> to change the shadow map range. The more the range, the less the resolution (default value is 5 meters)
* Rembrandt has strict needs with shaders => shaders need to be adjusted to comply with the new framework otherwise the view will be plain wrong
* Rembrandt can't do transparent surfaces => transparent surface need to be properly registered to render them with the classical path
Once your aircraft has been ported, please modify its wiki page and add this symbol to it:
For a list of converted aircraft, please see [].
=== Registering all translucent surfaces ===
If opaque surface need to have special effect, for example to apply bump mapping, this effect should use the "RenderBin" bin, or the rendering hint set to "opaque", and the G-buffer needs to be initialized correctly in the Geometry stage.
A surface that uses the [[ALS technical notes#ALS glass effect|ALS glass effect]] does not need to be separately registered for Rembrandt, this is done automatically.
=== Making sure that all geometry will cast shadow ===
To limit the amount of geometry rendered in the shadow map, and also to reduce artifacts (shadow acne), only faces not facing the sun are casting shadows. The test is made using the normal orientation. That means that double-sided polygons, or mesh that are not closed, will be transparent to light at certain sun angles. To avoid that, modelers can either :
* ensure that the object is always in the shadow of another objects,
* close their mesh, or,
* double polygons with the normal set to the opposite.
=== Adding lights to a model ===
|Three element vector. <c> element is the constant factor, <l> element is the linear factor and <&lt;q> &gt; element is the quadratic factor.<br />
Attenuation of color at distance d is [[File:Spotlight_attenuation.png]]
=== Tutorials ===
[[User:F-JJTH|F-JJTH]] compiled his experience and the one acquired by the PAF team converting aircraft in {{fr}} [ this tutorial],
== TODO List ==
=== Mac Issues ===
More and more Apple/Mac users are reporting issues related to running Rembrandt [].
Looking at the Mac GPU specs, it isn't clear if the Mac/ATI hardware/driver is generally insufficient, it should seem possible to run a customized Rembrandt setup with acceptable frame rates at 15-35 fps (assuming everything else being disabled for starters).
GLSL compilers have varying quality and especially the Mac (ATI/AMD) GLSL compilers are known to have issues with more sophisticated/nested constructs, so that it may help to reduce complexity of GLSL statements by splitting them up, instead of using nested anonymous vectors or functions (fatal error C9999: Nested functions, aborting!) for example.
So, the specific issue on Mac is some shaders being miscompiled, so the frame-rates are particularly bad, since the driver is hitting (slow) error paths. Certainly some Rembrandt-related shades fail to compile, though whether or not these are optional or required ones, isn't clear (Fred?). Some users reported that the errors and problems after upgrading their OS from OsX, 10.6.8 to OSX 10.8.2 (Mountain Lion) [] or OS Snow Leopard (10.6. to Mountain Lion (10.8.2), downloaded XQuartz 2.7.4 [].
The shader errors would suggest that certain GLSL constructs are not supported by the ATI/AMD glsl compiler - this seems to be a known issue: [!topic/] To address this, one would need to port the corresponding shaders - like just was done to get rid of the constructs that caused errors on old GeForce 7x generation hardware. It seems the hardware is not the problem, but the driver being way out of date. I find the fact that it's the Cg compiler and not a native glsl compiler that returns the errors very strange.
Another FG 2.10 user on MacPro 3.2 GHz Quad-Core Xeon, 8GB RAM, MacOS X 10.6.8. ATI Radeon HD 5870 (gl-vendor:ATI Technologies Inc., gl-version:2.1 ATI-1.6.36 gl-renderer:ATI Radeon HD 5870 OpenGL Engine, gl-shading-language-version:1.20) report said "Rembrandt is still unusable on my Mac. One frame every 4-5 seconds and it looks weird."[]
It's also worth noting that a number of FG 2.8 users reported that Rembrandt would still work for them using the 2.8 binary, unlike the 2.10 binary on Mac OSX version 10.7.5 on an iMac (AMD Radeon HD Graphics with 512MB) []. So the issue seems to occur largely in combination with older Mac OS versions and newer FG versions (>=2.8+) [].
It appears it is the Rembrandt lighting causing issues while in non rembrandt mode with older Mac OS + FG 2.8 and better. On other OS setups, the rembrandt lighting gets ignored when rembrandt is turned off, but not in this case. Both lighting modes are present and creating the weird light cone effects [].
If there are any console messages (like warnings or errors) shown, that would be helpful to know. A number of rembrandt related changes got fixed by Fred like this. Obviously, it is difficult for shader developers to troubleshoot shader related issues that they cannot reproduce with their own hardware.
Rembrandt is being largely developed by a single Windows/Nvidia-based developer, so it gets very little testing and debugging on different platforms, especially Mac/ATI (AMD) - so as a Mac user, your safest bet is probably providing lots of feedback via the forums (or preferably the issue tracker), FredB (the Rembrandt developer) is generally pretty responsive and appreciates all helpful feedback. Obviously, it helps being able to build from source, and being able to provide detailed troubleshooting reports.
These things are hard to debug/troubleshoot without having access to a corresponding system that exhibits the problem, which is why I suggested earlier to provide lots of Mac/Rembrandt-related feedback via the issue tracker, i.e. GLSL errors/warnings and anything else that could be useful.
If you have you ever tried to debug an issue that doesn't cause errors on your computer, you'll understand that it's damn difficult in the first place. Most developers don't own a Mac, and are not going to spend 1000$ or so just to have one more computer to test things on, and we don't know of anyone who buys computers for the whole purpose of testing FG on more platforms.
So as a rule we can try to pin down and solve such issues if, and only if, we get a decent bug report with tons of relevant background info and the possibility to ask follow-up questions. Remember, fixing such issues involves essentially working blind - it is trying to figure out why code that runs pefectly fine on your own computer might have issues on other computers and any traditional bug-hunting technique essentially fails.
Posting a screenshot of the issue is nice, but tells little more than that it exists. It's completely impossible to turn that into any action developer-side. The underlying shader code has probably a combined 1000 lines, any of which could be problematic.
Overall, the Rembrandt situation is most likely to improve the more feedback is provided by end users with different hardware/software configurations, Fred has fixed quite a number of shader related issues in the past, so it's largely a matter of time, and obviously the quality of feedback, provided by end-users like yourself.
And just in case: Note that GLSL shaders are not really compiled/built by developers (unlike the actual fgfs binary), but on an invididual basis by your GPU/graphics drivers, which happens transparently in the background, each time fgfs is started. Basically, a GLSL shader is a snippet of "source code" that is passed on to your GPU driver, which in turn compiles it down into hardware-specific instructions for your particular hardware.
From a troubleshooting perspective, it would be REALLY helpful if Mac users with the corresponding hardware and knowledge could come up with extremely downstripped test cases, that either show the problem, or which no longer show the problem as significantly. Disabling other shader-based features will definitely go a long way here, because many other GLSL features have not yet been explicitly ported to support Rembrandt.
In other words, you should preferably disable random building, advanced light scattern, advanced weather etc - and only really use the most basic settings to have an easily reproducable test case.
To get this started, you can customize the "zero eye candy" profile and enable Rembrandt using shader level 1: [[Howto:Debugging_FlightGear_Crashes#Minimal_Rembrandt_Startup_Profile]]
Some Mac folks have recently reported some success, it may be a good idea to search the forum for details, see for example:
{{cquote|I'm seeing regular crashes here from ALS and Rembrandt, but that's nothing new.<ref>{{cite web |url=|title=<nowiki>Re: [Flightgear-devel] 2.10.1</nowiki>|author=Vivian Meazza|date=Fri, 03 May 2013 10:16:13 -0700}}</ref>|Vivian Meazza}}
{{cquote|With an AMD Radeon HD 5670 using free radeon driver I've never seen performance of more than 15fps with Rembrandt and if I turn shadow details up so they don't look crappy I get about 3-4fps.<ref>{{cite web |url=|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stefan Seifert|date=Thu, 20 Jun 2013 10:10:56 -0700}}</ref>|Stefan Seifert}}
{{cquote|with a i3770K and a GTX670, I get some hit from ALS (10-30%) but Rembrandt instantly drops me to 20fps, and < 10fps I use an aircraft I actually want to fly (777 or Citation) and go to any major airport (EGKK, EHAM, EDDM, EDDF, EGLC, VHHH)
This is at 2560x1600, but on the 670 I would be highly surprised if I'm fill-rate limited, given that AA is off, and the general suboptimal size of our
primitive batches.
Emilian has explained on IRC this might be due to the out-of-the-box / default config for Rembrandt being highly suboptimal, which I didn't yet evaluate, I would be delighted to have it more usable.<ref>{{cite web |url=|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=James Turner|date=Thu, 20 Jun 2013 13:29:47 -0700}}</ref>|James Turner}}
{{cquote|The Apple OpenGL renderer is a rather interesting beast - it's a clean-room front-end to the drivers, one of aspect of which means it is the only true 'Core Profile' 3.x renderer in wide use. (As opposed to the Ati and Nvidia Core profile drivers, which are simple the compat ones with some checks removed, I have been told). Of course FG is hence limited to 2.1 on Mac since we're a long way from Core profile support in the main code.
This does however mean it produces different GLSL compile issues, and different bugs in general, from the same hardware on other platforms.
(The renderer backend does of course come from the vendors, but OpenGL.framework always comes from Apple - it's not like Linux where your comes, at least potentially, from your hardware vendor)<ref>{{cite web |url=|title=<nowiki>Re: [Flightgear-devel] Shader compile failure</nowiki>|author=James Turner|date=Sat, 11 May 2013 06:53:32 -0700}}</ref>|James Turner}}
{{cquote|concerning the larger issue of different rendering pipelines / approaches, my opinion is, and remains, that the long-term solution is separate viewer codebases - while a plethora would be bad, we would already benefit from a 'fixed-function, no shaders' renderer codebase distinct from a Rembrandt renderer and modern, forward-rendering OpenGL 3.x pipeline. This needs the viewer to be cleanly split out from the simulation backend, via HLA, which is exactly what Mathias (and soon, myself) are working towards, but slowly.<ref>{{cite web |url=|title=<nowiki>Re: [Flightgear-devel] Atmospheric Light Scattering</nowiki>|author=James Turner|date=Thu, 25 Apr 2013 08:09:08 -0700}}</ref>|James Turner}}
{{cquote|Like you and Thorsten, I see a very significant drop (50%) in frame-rate with Rembrandt, even without most the nice features such as shadows which has put me off using it. I had thought it was just because my box is now underpowered (the march of technology....) but it sounds like other are
seeing similar issues and it would be worth some further investigation.<ref>{{cite web |url=|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stuart Buchanan|date=Fri, 21 Jun 2013 01:40:15 -0700}}</ref>|Stuart Buchanan}}
=== Completed tasks ===
*Move effect of cloud coverage from water shader to sunlight shader
*Allow light masks using textures
*Render Use stencil double-sided operations to limit the depth of light volumes with back face culling and . Use depth clamp instead of to ensure front face culling, and don't light pixels faces are always rendered even if the camera is enclosed in from of the light volume.
=== Long term ideas (unsorted) ===
*Use a separate list of light volumes to avoid traversing the scenegraph again (with transparency problems). Find out how we can detect unloading of models.
*implement volumetric effects by extending lights to arbitrary shaders. Should enable to implement heat haze effect and real wake waves.
*implement strength of glow (in the emissive buffer alpha channel) - use a Poisson-disk distribution to implement variable size blur
* {{cite web |url= |title=Graphics Tech: Shadow Maps (part 1) |author=Jonathan Blow |date=3 March 2010 |accessdate=13 April 2012 }}
* {{cite web |url= |title=deferred rendering in frameranger. |author=Matt Swoboda |date=13 November 2009 |accessdate=8 July 2012 }}
* {{cite web |url= |author=DICE |title=Publications on rendering |accessdate=15 August 2012 }}
* {{cite web |url= |author=Martin Mittring |title=The Technology behind the Unreal Engine 4 Elemental Demo |accessdate=15 September 2012 }}
[[Category:Shader development]]
[[Category:Core development projects]]
[[fr:Projet Rembrandt]]

Navigation menu