Understanding Rembrandt: Difference between revisions

Jump to navigation Jump to search

Understanding Rembrandt (view source)

Revision as of 18:41, 4 January 2015

7,511 bytes added ,  4 January 2015
m
no edit summary
(some comments/ corrections about Rembrandt)
mNo edit summary
Line 118: Line 118:


I think through roughly a dozen different test cases like these, one could incrementally understand rembrandt and its stages - obviously, one would now need to edit some of the XML files and maybe some effects/shaders to see how things are affected
I think through roughly a dozen different test cases like these, one could incrementally understand rembrandt and its stages - obviously, one would now need to edit some of the XML files and maybe some effects/shaders to see how things are affected
== Internals ==
{{FGCquote
  |Rembrandt has GLSL components (all the *-gbuffer shaders are Rembrandt GLSL code), but Rembrandt needs some additional 'infrastructure' set up - the buffers it renders into being the most important, and a special definition of the sequence of rendering. Such buffers don't feature in a fixed pipeline rendering or in forward rendering. I believe they could theoretically all be set up runtime as well. I don't understand this too well, but I think it's a bit akin to the reset problem in Flightgear - seems easy, but there's a lot of smallprint to consider. It's much easier to create the infrastructure at startup time.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221188#p221188
    |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki>
    |author=<nowiki>Thorsten</nowiki>
    |date=<nowiki>Sun Oct 19</nowiki>
  }}
}}
{{FGCquote
  |Internally, a Rembrandt buffer is not much different from any other RTT context - Canvas is all about rendering to a dynamic texture and updating it dynamically by modifying a sub-tree in the property tree - but its primary primitives are 1) osgText, 2) shivaVG/OpenVG paths, 3) static raster images, 3) groups/maps - none of these would be particularly useful in this context. But Zan's newcamera work could be turned into a new "CanvasCamera" element to allow camera views to be rendered to a Canvas, including not just scenery views - but also individual rendering stages. Canvas itself maintains a FBO for each texture, which is also the mechanism in use by Rembrandt. Tim's CameraGroup code is designed such that it does expose a bunch of windowing-related attributes to the property tree - equally, our view manager is property-controlled. <br/>
<br/>
For a WIP-intro, refer to: [[The_FlightGear_Rendering_Pipeline]]
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221229#p221229
    |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sun Oct 19</nowiki>
  }}
}}
{{FGCquote
  |it's all the init/setup code that is hard-coded, and which used to contain a few hard-coded shaders - those are basically different rendering buffers that are chained together to set up a deferred rendering pipeline - this isn't done in a "plug &amp; play" fashion currently - exposing this to XML/property tree space would be a huge undertaking probably - Zan's "newcamera" work really is the best match here - and RTT/buffer management is exactly what Canvas is already doing under the hood.
Thus, each RTT buffer could simply be a Canvas texture internally - so that all the hard-coded Rembrandt logic could be maintained more easily at some point.
It is indeed lack of consistency and integration that is the main challenge here - because all of these features were developed at a different point in time, and people were usually only interested in making one thing work, instead of unifying those solutions (effects + newcamera branch +  Canvas). And it is indeed a lot of work to do this properly - a unified approach takes a  lot of time and energy.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221193#p221193
    |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sun Oct 19</nowiki>
  }}
}}
{{FGCquote
  |Rembrandt pre-dates the whole reset/re-init effort by several years, and while SGSubsystem does provide the corresponding interfaces to be implemented by each subsystem to handle simulator resets, our rendering system isn't a conventional SGSubsystem - equally, all the CameraGroup stuff has become fairly massive meanwhile.
It is definitely possible to implement dynamic reset/re-init even for the renderer, including all buffers and windows/views - Zan's work still is the most promising effort in this department.
But that, too, predates the whole Canvas  effort.
Like wlbragg said: we don't necessarily need to use a lot of dedicated C++ support code to implement alternate rendering schemes like Rembrandt, the main hooks required to support arbitrary -and fully dynamic- schemes is already in place.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221223#p221223
    |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sun Oct 19</nowiki>
  }}
}}
{{FGCquote
  |Internally, FG doesn't usually use the C/C++ APIs for GLSL directly, but uses the OSG abstraction layers instead (which are fairly well documented, even for people new to shaders).
The "obscure" parts of Rembrandt are not necessarily its effects or shaders, but the underlying C++ code which sets up all the buffers and  sequencing. Once that is either documented or exposed, it is foreseeable that deferred rendering will be resurrected again, even if FredB should still not be around - such an effort would not need to involve Zan's work or Canvas, but it would be the most logical step for the time being, absent some other overlapping development effort.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221223#p221223
    |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sun Oct 19</nowiki>
  }}
}}
{{FGCquote
  |It basically works like this:<br/>
<br/>
<ul>
<li> FlightGear contains an effects subsystem that integrates shaders + properties and materials ({{=}}textures)</li>
<li> the effects subsystem is using the OSG abstraction layer for GLSL like you say</li>
<li> FlightGear itself has all the viewer/renderer logic in $FG_SRC/Viewer</li>
<li> Rembrandt needs buffers set up, initialized and updated beyond what's possible via fgdata-space additions, such as Nasal, effects, shaders</li>
<li> this is why FredB took the  existing "fixed pipeline" code and adapted it to set up a bunch of buffers for all deferred rendering stages</li>
<li> and then, a few hard-coded shaders are/were associated with some buffers</li>
<li> incrementally, Fred then started to adopt the effects subsystem to move hard-coded shaders out of C++ into $FG_ROOT (fgdata)</li>
<li> thus, Rembrandt does indeed uses effects and shaders primarily now - but all the setup/init and update logic still resides in C++</li>
<li> many of the performance implications associated with Rembrandt were linked to its C++ code</li>
<li> people primarily doing fgdata-level effects/shader development are thus in an exceptionally bad situation to help improve/maintain Rembrandt, because the whole integration is not sufficiently documented, and it can really only be changed via C++ additions.</li>
<li> we've seen other C++ patches rejected, despite the  corresponding subsystems having active/involved maintainers</li>
<li> several core developers have repeatedly stated that they won't target/support Rembrandt due to its known performance implications</li>
<li>in its current form, the setup/init logic isn't designed to be dynamically adjusted, i.e. many attributes are not yet exposed to properties/listeners, or only read during startup</li>
<li>this is a common trait of C++ code that didn't quite progress beyond "prototyping" - it took Zakalawe almost 2 years to implement reset/re-init support in its current form </li>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221229#p221229
    |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sun Oct 19</nowiki>
  }}
}}




[[Category:Shaders]]
[[Category:Shaders]]
[[Category:Shader development]]
[[Category:Shader development]]
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/78845"

Navigation menu