Hello,about GLEWX, it seems that the official 1.9.0 tar ball from sourceforge (from 2012), and I think the one that buildyard is getting down have a missigng header guard:
See http://sourceforge.net/p/glew/code/ci/6d14805de58321e8a7b1881323e604bb0ba27217/tree/auto/src/glxew_mid.h?diff=38a3d857549e7ac31b7edb2a1cfa1ead52f72220
This gives a lot of trouble when linking things like bino.As well for FindGLEW_MX.cmake, I think it would be good to add a $ENV{GLEWDIR}/include and $ENV{GLEWDIR}/lib in the search paths.
This issue was giving multiple definitions errors and I got stuck with that until now.
Regards Dr. Raimondo Giammanco HPCC & IT Service Head von Karman Institute Chee De Waterloo 72 B-1640 Rhode-St-Genese Belgium http://www.vki.ac.be TEL: +3223599764 FAX: +3223599600 On 13/06/2013 08:56, Stefan Eilemann wrote:
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.
<<attachment: giamma.vcf>>
_______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
