Re: [Flightgear-devel] Announcing Project Rembrandt

[Mathias F. <Mat...@gm...>]

Hi,

On Friday, December 30, 2011 11:45:21 Frederic Bouvier wrote:
> The problem I have to solve currently is how to feed the G-Buffer
> to the Effect system because the textures used to store it are
> camera-dependent (in a multi screen context) but the pass (which
> is a stateset) is built once for all.
I do not exactly understand. I see that the effects collide in some sense with 
this kind of an approach. Partly effects do try to achieve some similar results 
in the good old fixed function derived world, than you get once your code is 
used, but as far as I see, the intermediate screen sized textures sould not be 
processed anymore with the effects? Or at least how would you know which 
fragment to process with witch effect? Or I think that all the effects probaly 
need to be changed to write their color/reflection/whatever information into 
the appropriate render target?

So, far how I understand the question. I am almost sure I miss your point.

Ahh, ok do you want to write the compositing step as a usual effect file?
Then, I understand the problem. Well, If this is the problem, I do also not 
see an easy solution. I would think that this final compositing step is so 
different from the rest off the effect stuff, that inseriting these textures using 
non generic custom code for this special purpose is fine.
So, for this kind of problem currently no solution - may be one when I think 
about this for some time.
Let me know If I am looking at the right problem ...

> Currently, the fog is computed using the depth buffer as a post-process
> pass. Any smarter computation (like atmospheric scattering) is just
> a matter of writing a single shader that would replace the default
> fog computation.
Exactly. And you are looking into the sky if you find a far clipping plane 
depth value.

> > So, may be just one question for what you have done already again
> > without looking into any code:
> > 
> > You do not require float textures?
> > As far as I can see, there is a patent issue on this extension and
> > usually this is not strictly required.
> > Using a fixed point representation that makes use of the usual
> > depth buffer - one that scales differently than the usualy
> > perspective depth - could be used instead and I think we should
> > use this in the end. In the end this really gives even better
> > accuracy than a float representation since floats waste some
> > bits for the expontent, where a fixed point representation could
> > just use all the bits for accuracy.
> 
> I used Policarpo's tutorial on deferred shading so I don't store
> absolute world position in a float texture. As described in the
> tutorial, I used the view direction and the depth value to compute
> the eye space position of the fragment.
That's fine! That's what I had in mind also. The fragment position gives the 
vew direction by the projection matrix and together with the depth value fed 
through the inverse projection matrix yields the right values.

> Nevertheless, I use float texture to store the normals. I tried
> setting up a normal buffer with just luminance and alpha with
> half-float while the color buffers were rgb8 but it was very slow.
> Instead I used rgba16f for all textures (except the depth buffer).
> As I use additive blending to collect the lights, I thought it
> would be possible to have some kind of HDR without the risk of
> saturating the 8bit color components. I can try to use 2 color
> channels to store the x and y components of the normal and
> reconstruct the z part with sqrt(1 - (x^2+y^2)) but that won't
> solve the saturation issue. Some use LUV color space to store
> higher intensity in RGB8 but afaik, it don't support additive
> blending.

Ok, I have not thought at the normals yet. Lets first make this work and then 
care for a fallback or nice trick that does not need float textures and looks 
fine performance wise.

Greetings

Mathias