[eq-dev] Compositing and eq::Window/eq::Channel inheritance

[cpapado]

Hey Stefan & gang,

I am trying to use EQ-driven compositing in our rendering framework to
achieve bezel compensation.

My intuition on this was as follows.

-> Render the scene in a pbuffer window (FBOs don't seem to work with our
hardware but that's another issue) that spans the entirerity of the canvas
to be drawn (including bezels).
-> Create windows that cover the visible surfaces of the canvas.
-> Create output frames off the backbuffer surface
-> Composite the output of those frames on the final (visible) window.

I believe that the above is possible.

However, I've come across an issue. In our framework, I've subclassed
eq::Window and added a bunch of code for doing (among other things) scene
loads. Generally speaking, the windows on which the composition happens
should not need any of the additional functionality that I have added to the
eq::Window class. What would be the best way to differentiate between an
actual backbuffer rendering surface and visible window in the case described
above? Is there some way to reach the window name defined in the config file
from inside eq::Window? Is there some other accepted eq coding practice that
I am not aware of?

Thanks everyone!

-Harris

--
View this message in context: http://software.1713.n2.nabble.com/Compositing-and-eq-Window-eq-Channel-inheritance-tp7518113.html
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.

_______________________________________________
eq-dev mailing list
eq-...@equalizergraphics.com
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[Stefan Eilemann]

Hi Harris,

On 1. May 2012, at 22:56, cpapado wrote:

> However, I've come across an issue. In our framework, I've subclassed
> eq::Window and added a bunch of code for doing (among other things) scene
> loads. Generally speaking, the windows on which the composition happens
> should not need any of the additional functionality that I have added to the
> eq::Window class. What would be the best way to differentiate between an
> actual backbuffer rendering surface and visible window in the case described
> above? Is there some way to reach the window name defined in the config file
> from inside eq::Window?

Window::getName() is always a last-resort hack to do specializations like you describe. I however always try to find another way which doesn't rely on special configs. Configs are supposed to be generic, and will become more and more auto-generated.

> Is there some other accepted eq coding practice that
> I am not aware of?

What has emerged as a pattern is to delay rendering-specific initialization to the first Channel::frameDraw which needs it. This also works nicely with DB compounds, where you only want to load the partial data needed by a given resource. Even better, if feasible, is to do the initialization in an asynchronous thread and render a 'loading...' in the channel while this is going on. This keeps the application responsive.


HTH,

Stefan.

[cpapado]

Thanks for the reply Stefan. I'll get back to the "channel/window
differentiation" issue later, I am having a more fundamental problem.


I am trying to set up a config for the task described in my original post. I
have successfully written a configuration that will render the scene into an
off screen buffer (pbuffer since FBOs don't work for some reason on my
system) then cut pieces of that buffer and drop them into two other EQ
windows. This (working) config is here: http://pastebin.com/yzEw7y6j

I want to adapt this config so that instead of using two destination WINDOWS
it uses a single destination window with multiple channels (the motivation
behind this is to avoid a whole bunch of OpenGL context switching + an
OpenGL context number limitation that we seem to have ran into with the
hardware/drivers we are using). This config can be found here:
http://pastebin.com/yDBXCNEy

I can't for the life of me figure out the proper compound syntax for the
second usecase...At most I have only been able to get the left hand side of
the window to render but that's it.

Do you have any insight on how to fix this?

Thanks a lot for your time!

-Harris

--
View this message in context: http://software.1713.n2.nabble.com/Compositing-and-eq-Window-eq-Channel-inheritance-tp7518113p7519189.html

Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.

[Stefan Eilemann]

On 2. May 2012, at 8:55, cpapado [via Software] wrote:

> Thanks for the reply Stefan. I'll get back to the "channel/window differentiation" issue later, I am having a more fundamental problem.

Just a quick answer as I'll need more time to look into it more detail:

Input/output frames are so far designed only for the use case of transporting them from source to destination for scalable rendering. The out-of-hierarchy stuff you're using certainly has issues with how the destination offset is calculated. IIRC your use case was discussed in more detail on this list a few years back. I guess it'll come down the a new feature request. The monitor equalizer, which does the reverse of what you need, works around this by having its own offset handling server-side.


Cheers,

Stefan.



--
View this message in context: http://software.1713.n2.nabble.com/Compositing-and-eq-Window-eq-Channel-inheritance-tp7518113p7519228.html

[cpapado]

Bummer...so would you say that there is no way to hack this with the current
config functionality offered by EQ?



--
View this message in context: http://software.1713.n2.nabble.com/Compositing-and-eq-Window-eq-Channel-inheritance-tp7518113p7519239.html

[Stefan Eilemann]

On 2. May 2012, at 9:25, cpapado wrote:

> Bummer...so would you say that there is no way to hack this with the current
> config functionality offered by EQ?

IIRC it needs an 'input frame { offset [ 0 0 ] name "" }' which shouldn't be that hard to implement.


Cheers,

Stefan.

[cpapado]

By the way, where is eq::Window::getName() defined? I can't seem to be able
to find it...

--
View this message in context: http://software.1713.n2.nabble.com/Compositing-and-eq-Window-eq-Channel-inheritance-tp7518113p7520428.html

Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.

[Stefan Eilemann]

On 2. May 2012, at 16:47, cpapado [via Software] wrote:

> By the way, where is eq::Window::getName() defined? I can't seem to be able to find it...

Here: http://equalizergraphics.com/documents/Developer/API/classeq_1_1fabric_1_1Object.html#af7f21d7c7e7b3a5f18e840c8a3cdfa24


Cheers,

Stefan.



--
View this message in context: http://software.1713.n2.nabble.com/Compositing-and-eq-Window-eq-Channel-inheritance-tp7518113p7520521.html