Discussion:
[Opensg-users] OpenSG 2: HDR example
Johannes Brunen
2016-03-01 16:52:31 UTC
Permalink
Hello,

I would like to build a HDR example. I have read the following chapter about HDR:

http://www.learnopengl.com/#!Advanced-Lighting/HDR

and now I try to get exactly that with OpenSG.

If I understand the article correct I do need to render into a floating point format color target. Here are some questions I have...

How do I get the floating point format render target if I use the HDRStage?
Where does it come from?
How can I setup my own tone mapping shader with the HDRStage?
Do I always have to pay for the shrinking and blurring stuff?
What does the shrinking do at all?
How can I rescue the depth buffer from the original scene rendering into the display depth buffer?

Sorry for bothering,

best,
Johannes
Carsten Neumann
2016-03-01 17:22:46 UTC
Permalink
Hello Johannes,
Post by Johannes Brunen
If I understand the article correct I do need to render into a floating
point format color target. Here are some questions I have...
How do I get the floating point format render target if I use the HDRStage?
Where does it come from?
I suspect that is controlled by the bufferFormat field of HDRStage.
Post by Johannes Brunen
How can I setup my own tone mapping shader with the HDRStage?
It does not look like that is a customization point at the moment.
Either making HDRStage::generateHDRFragmentProgram virtual (assuming a
new shader uses the same uniforms) or a new stage for your algorithm
would be needed.
Post by Johannes Brunen
Do I always have to pay for the shrinking and blurring stuff?
That is used for the bloom effect where bright light sources/surfaces
"bleed" into adjacent fragments. I guess the HDRStage could be optimized
to skip these steps if the settings that control them are at 0.
Post by Johannes Brunen
What does the shrinking do at all?
It makes the blur cheaper since it is only applied to a smaller texture
- blurring requires many texture samples making it a moderately
expensive thing memory bandwidth wise.
Post by Johannes Brunen
How can I rescue the depth buffer from the original scene rendering into
the display depth buffer?
Hmm, I don't recall how other stages handle that, does glBlitFramebuffer
work for the depth attachment?

Cheers,
Carsten
Johannes
2016-03-02 08:51:55 UTC
Permalink
Hello Carsten,

thanks for instant reply.
Post by Carsten Neumann
Post by Johannes Brunen
How do I get the floating point format render target if I use the HDRStage?
Where does it come from?
I suspect that is controlled by the bufferFormat field of HDRStage.
Sorry Carsten, but I did not formulate my question appropriate. What I
currently did not understand correctly is at what point does the
floating point render target, managed by the HDRStage, replaces the
normal display render target. It boils down to an understanding problem
of Stages, Partitions and grouping of the latter, I think. Could you
explain these concept for me?

Say I have 3 Stages s1, s2 and s3 that I have placed on top of each
other in the scene. Each stage does have its own render target defined.
How happens the hand shake between them and with the display draw
buffer? Which one is rendered first?

I would like to be able to write Stages myself and do need a thorough
understanding of what are the underlying rules and ideas.
Post by Carsten Neumann
Post by Johannes Brunen
How can I setup my own tone mapping shader with the HDRStage?
It does not look like that is a customization point at the moment.
Either making HDRStage::generateHDRFragmentProgram virtual (assuming a
new shader uses the same uniforms) or a new stage for your algorithm
would be needed.
I will think about it.
Post by Carsten Neumann
Post by Johannes Brunen
Do I always have to pay for the shrinking and blurring stuff?
That is used for the bloom effect where bright light sources/surfaces
"bleed" into adjacent fragments. I guess the HDRStage could be optimized
to skip these steps if the settings that control them are at 0.
Oh, I lacked the fantasy that this could be an implementation of the
bloom effect. Actually, I'm interested in this effect too :-)
Post by Carsten Neumann
Post by Johannes Brunen
How can I rescue the depth buffer from the original scene rendering into
the display depth buffer?
Hmm, I don't recall how other stages handle that, does glBlitFramebuffer
work for the depth attachment?
In principle it does. The recent FBOBackground and FBOForeground rely on
this feature.

This is important to me, since we need to render into the display buffer
after OpenSG render action has finished. For that the depth buffer must
be valid.

Same question arises for other Stages as well, especially for the
ShadowStage.

Best,
Johannes
Carsten Neumann
2016-03-02 21:16:10 UTC
Permalink
Hello Johannes,
Post by Johannes
Post by Carsten Neumann
Post by Johannes Brunen
How do I get the floating point format render target if I use the HDRStage?
Where does it come from?
I suspect that is controlled by the bufferFormat field of HDRStage.
Sorry Carsten, but I did not formulate my question appropriate. What I
currently did not understand correctly is at what point does the
floating point render target, managed by the HDRStage, replaces the
normal display render target.
HDRStage.cpp:164 with the setRenderTarget call on the partition.
Post by Johannes
It boils down to an understanding problem
of Stages, Partitions and grouping of the latter, I think. Could you
explain these concept for me?
Stages are the things you place in your scene graph to perform
"non-conventional" rendering - things that require multiple passes over
entire sub-graphs, rendering into a different render target,
pre-/post-processing of the resulting image.
Partitions are the things that represent these passes to the
RenderAction. They are created by the stages (sometimes multiple
partitions for a single stage) to perform the individual parts of a
rendering algorithm/effect. So the HDRStage creates a partition to
render into the floating point buffer and one to perform the post
processing.
IIRC partitions are executed in LIFO order, the innermost partition is
rendered first. In case of the HDRStage one would have to create the
post-processing partition before the render-to-float-buffer partition.
That is a bit counter-intuitive, hence there is also the concept of a
partition group. See HDRStage.cpp:143 this->beginPartitionGroup(a).
Inside a group the partitions are applied in the order they are added -
which allows specifying the two steps of the HDRStage in their "natural"
order.
Post by Johannes
Say I have 3 Stages s1, s2 and s3 that I have placed on top of each
other in the scene. Each stage does have its own render target defined.
How happens the hand shake between them and with the display draw
buffer? Which one is rendered first?
Order is s3, s2, s1. What target they render to depends on how they set
up the render targets of the partition(s) they create. Typically a stage
will put its final output into the target inherited from the parent
stage (which initially is the window framebuffer).
Post by Johannes
Post by Carsten Neumann
Post by Johannes Brunen
How can I rescue the depth buffer from the original scene rendering into
the display depth buffer?
Hmm, I don't recall how other stages handle that, does glBlitFramebuffer
work for the depth attachment?
In principle it does. The recent FBOBackground and FBOForeground rely on
this feature.
This is important to me, since we need to render into the display buffer
after OpenSG render action has finished. For that the depth buffer must
be valid.
Same question arises for other Stages as well, especially for the
ShadowStage.
Hmm, I don't remember the details, but this may be a missing feature for
some (most?) of the existing stages. I think they have been written with
the implicit assumption that their output goes to the final window
framebuffer and not necessarily that many of them get chained together
and get combined with other rendering - so preserving depth may not have
been built in yet.

Cheers,
Carsten

Loading...