Hi Petros,
On 11. Jun 2013, at 12:22, Petros.Kataras [via Software]
<[email protected]> wrote:
> Just to give an idea the projects consists of Equalizer , openFrameworks, an
> in-house wrapper around Equalizer that makes Eq usage a bit simpler for our
> usual application cases ( it has been used for some time and it works pretty
> well )
How does it compare to Sequel? ANy chance of merging the two?
> Now OF does have its own GLEW-GLXEW stuff so at that point I thought that
> there must be some kind of conflict between Eq and OF, on that end, although
> a quick look didnt gave my any apparent hints.
At this point I would really start using an external GLEW_MX library for both
projects. FindGLEWMX in Equalizer should pick it up.
I hope we're using the same version?
> So as I mentioned I narrowed it down to the specific check on the Eq side
>
> if( !GLXEW_VERSION_1_3 && !GLXEW_SGIX_fbconfig ) { ... }
>
> and as a quick and dirty test I just commented out the specific part I was
> able to run everything properly without any failures or weird results..
>
> I definitely have to get into it in more detail though and understand why
> this is happening..
These macros really just 'jump into' the GLXEWContext struct to look up values.
You can probably just examine this struct in your debugger.
> Our most standard application case consists of multi-display walls where we
> have a master machine and a cluster of renderers .
>
> So I suppose what we are mostly interested right now is being able to render
> two outputs where each output renders half of the master output .( this is
> just a test case -- Ideally this expands then to more nodes - displays etc .)
Then just have a look at 2-node.eqc and modify the canvas wall.
> Hope this makes sense.. As for the pixel coordinates I understand your
> thoughts but I was thinking that if all of these stuff reach a wider audience
> and especially an openFrameworks audience it would maybe be simpler to work
> with and logically understand it..
...until you want to do stereo or immersive, at which point it bites back since
reality no longer matches your projection system.
> On the other hand if you have any other suggestions please let me know !!
I'm really missing what the pixel correspondence is needed for. I got out on a
limp and say 2D overlays - which one can easily render from frameViewFinish
using Channel::applyScreenFrustum:
* Apply an orthographic frustum for pixel-based 2D operations.
*
* One unit of the frustum covers one pixel on screen. The frustum is
* positioned relative to the view.
HTH,
Stefan.
--
http://www.eyescale.ch
https://github.com/Eyescale/
http://www.linkedin.com/in/eilemann
--
View this message in context:
http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583402.html
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
