Hello Johannes,
On 2016-03-02 02:51, Johannes wrote:
> On 01.03.2016 18:22, Carsten Neumann wrote:
>> On 2016-03-01 10:52, Johannes Brunen wrote:
>>> 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.
> 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.
> 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).
>>> 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
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
