Hello Johannes,
Post by JohannesPost by Carsten NeumannPost by Johannes BrunenHow 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 JohannesIt 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 JohannesSay 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 JohannesPost by Carsten NeumannPost by Johannes BrunenHow 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