[eq-dev] Pixel Coordinates configuration file - OF - Equalizer
21 views
Skip to first unread message
Petros.Kataras
Jun 10, 2013, 6:29:55 AM6/10/13
to eq-...@equalizergraphics.com
Hi All,
We are doing an attempt to hook Equalizer with openFrameworks. There was a
previous in-house attempt a few years ago but for various reasons it was
dropped at that point .. Now that both frameworks and especially OF has a
much more mature and clean API it seems like a good point to make this
attempt again!
The idea would be to release the outcome in some way when its clean and
functional enough .. The integration has been quite smooth so far with the
exception of a couple of points which I would like to share with you in
order to maybe have some feedback..
An issue that I encountered during the integration was that Equalizer was
failing this check :
if( !GLXEW_VERSION_1_3 && !GLXEW_SGIX_fbconfig )
{
...
}
whenever instantiating an OF object ..
Trying to get a bit deeper to the root of the issue I exported
EQ_LOG_LEVEL=INFO and the application was not failing anymore at that
specific check .. It made me think that there must be an issue of
initialization order or something related to GLEW but I never got into the
bottom of the issue because just by commenting out the above block on Eq
everything seems to run perfectly fine .. My plan though is to get back to
this and any hints or ideas would be more than welcome !
To the actual usage now , I have a 1-window config based on pixel
coordinates with a wall description like this which works perfectly fine and
as expected :
bottom_left [ -w/2 -h/2 -1 ]
bottom_right [ w/2 -h/2 -1 ]
top_left [ -w/2 h/2 -1 ]
Now I am testing a 2-node config logically translated from this wall
description in order for each client to render half of the scene so
something like this :
client1
bottom_left [ -w/2 -h/2 -1 ]
bottom_right [ 0 -h/2 -1 ]
top_left [ -w/2 h/2 -1 ]
client2
bottom_left [ 0 -h/2 -1 ]
bottom_right [ w/2 -h/2 -1 ]
top_left [ 0 h/2 -1 ]
but I am not able to get what I would expect..
I attach my config file and two snapshots of what I get on order to make it
a bit more clear ..
Am I missing something really obvious here ?? Thanks for any hints / help
and sorry for the long post !
Petros
2-node.eqc <http://software.1713.n2.nabble.com/file/n7583381/2-node.eqc>
master.png <http://software.1713.n2.nabble.com/file/n7583381/master.png>
clients.png <http://software.1713.n2.nabble.com/file/n7583381/clients.png>
-----
Creative Engineer
Ars Electronica Futurelab
petros....@aec.at
--
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381.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
We are doing an attempt to hook Equalizer with openFrameworks. There was a
previous in-house attempt a few years ago but for various reasons it was
dropped at that point .. Now that both frameworks and especially OF has a
much more mature and clean API it seems like a good point to make this
attempt again!
The idea would be to release the outcome in some way when its clean and
functional enough .. The integration has been quite smooth so far with the
exception of a couple of points which I would like to share with you in
order to maybe have some feedback..
An issue that I encountered during the integration was that Equalizer was
failing this check :
if( !GLXEW_VERSION_1_3 && !GLXEW_SGIX_fbconfig )
{
...
}
whenever instantiating an OF object ..
Trying to get a bit deeper to the root of the issue I exported
EQ_LOG_LEVEL=INFO and the application was not failing anymore at that
specific check .. It made me think that there must be an issue of
initialization order or something related to GLEW but I never got into the
bottom of the issue because just by commenting out the above block on Eq
everything seems to run perfectly fine .. My plan though is to get back to
this and any hints or ideas would be more than welcome !
To the actual usage now , I have a 1-window config based on pixel
coordinates with a wall description like this which works perfectly fine and
as expected :
bottom_left [ -w/2 -h/2 -1 ]
bottom_right [ w/2 -h/2 -1 ]
top_left [ -w/2 h/2 -1 ]
Now I am testing a 2-node config logically translated from this wall
description in order for each client to render half of the scene so
something like this :
client1
bottom_left [ -w/2 -h/2 -1 ]
bottom_right [ 0 -h/2 -1 ]
top_left [ -w/2 h/2 -1 ]
client2
bottom_left [ 0 -h/2 -1 ]
bottom_right [ w/2 -h/2 -1 ]
top_left [ 0 h/2 -1 ]
but I am not able to get what I would expect..
I attach my config file and two snapshots of what I get on order to make it
a bit more clear ..
Am I missing something really obvious here ?? Thanks for any hints / help
and sorry for the long post !
Petros
2-node.eqc <http://software.1713.n2.nabble.com/file/n7583381/2-node.eqc>
master.png <http://software.1713.n2.nabble.com/file/n7583381/master.png>
clients.png <http://software.1713.n2.nabble.com/file/n7583381/clients.png>
-----
Creative Engineer
Ars Electronica Futurelab
petros....@aec.at
--
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381.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
Jun 11, 2013, 5:07:52 AM6/11/13
to Equalizer Developer List
Hi Petros,
On 10. Jun 2013, at 12:29, Petros.Kataras <petros....@aec.at> wrote:
> We are doing an attempt to hook Equalizer with openFrameworks.
Nice - finally!
> An issue that I encountered during the integration was that Equalizer was
> failing this check :
>
> if( !GLXEW_VERSION_1_3 && !GLXEW_SGIX_fbconfig )
> {
> ...
> }
>
> whenever instantiating an OF object ..
>
> Trying to get a bit deeper to the root of the issue I exported
> EQ_LOG_LEVEL=INFO and the application was not failing anymore at that
> specific check .. It made me think that there must be an issue of
> initialization order or something related to GLEW but I never got into the
> bottom of the issue because just by commenting out the above block on Eq
> everything seems to run perfectly fine .. My plan though is to get back to
> this and any hints or ideas would be more than welcome !
The GLXEW_FOO macros resolve into glxewGetContext()->foo, where the context is a lookup table to the function pointers and feature bools. This function has to be defined in the context you've got the macro, and resolve to the correct GLXEWContext.... which you can't because I just realize it's never exported from eq::glx::Pipe. I'll look into it.
How did you get it to compile?
> To the actual usage now , I have a 1-window config based on pixel
> coordinates with a wall description like this which works perfectly fine and
> as expected :
>
> bottom_left [ -w/2 -h/2 -1 ]
> bottom_right [ w/2 -h/2 -1 ]
> top_left [ -w/2 h/2 -1 ]
>
> Now I am testing a 2-node config logically translated from this wall
> description in order for each client to render half of the scene so
> something like this :
Do you want the two clients to render one output (scalability) or two (powerwall)?
Also, I'm not sure pixel-based coordinates are a good idea. Configs are supposed app-independent and use real-world coordinates. This helps a lot in setting up VR stuff. The canvas/layout concepts brings back 2D connectivity... If you describe your use case I'm sure I can point you in the right direction.
Cheers,
Stefan.
--
http://www.eyescale.ch
https://github.com/Eyescale/
http://www.linkedin.com/in/eilemann
On 10. Jun 2013, at 12:29, Petros.Kataras <petros....@aec.at> wrote:
> We are doing an attempt to hook Equalizer with openFrameworks.
> An issue that I encountered during the integration was that Equalizer was
> failing this check :
>
> if( !GLXEW_VERSION_1_3 && !GLXEW_SGIX_fbconfig )
> {
> ...
> }
>
> whenever instantiating an OF object ..
>
> Trying to get a bit deeper to the root of the issue I exported
> EQ_LOG_LEVEL=INFO and the application was not failing anymore at that
> specific check .. It made me think that there must be an issue of
> initialization order or something related to GLEW but I never got into the
> bottom of the issue because just by commenting out the above block on Eq
> everything seems to run perfectly fine .. My plan though is to get back to
> this and any hints or ideas would be more than welcome !
How did you get it to compile?
> To the actual usage now , I have a 1-window config based on pixel
> coordinates with a wall description like this which works perfectly fine and
> as expected :
>
> bottom_left [ -w/2 -h/2 -1 ]
> bottom_right [ w/2 -h/2 -1 ]
> top_left [ -w/2 h/2 -1 ]
>
> Now I am testing a 2-node config logically translated from this wall
> description in order for each client to render half of the scene so
> something like this :
Also, I'm not sure pixel-based coordinates are a good idea. Configs are supposed app-independent and use real-world coordinates. This helps a lot in setting up VR stuff. The canvas/layout concepts brings back 2D connectivity... If you describe your use case I'm sure I can point you in the right direction.
Cheers,
Stefan.
--
http://www.eyescale.ch
https://github.com/Eyescale/
http://www.linkedin.com/in/eilemann
Petros.Kataras
Jun 11, 2013, 6:22:53 AM6/11/13
to eq-...@equalizergraphics.com
Hi Stefan,
Thanks for your prompt reply !
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 ) and finally now a second wrapper that I am writing that aims to bring
all these parts together ...
> How did you get it to compile?
I didn't face any issues during compilation -- The problem would manifest
during runtime in any attempt to instantiate an openFrameworks object, by
throwing a GLXWindow initialization error stating that no matching pixel
format was found ..
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.
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..
>Do you want the two clients to render one output (scalability) or two
(powerwall)?
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
.)
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..
On the other hand if you have any other suggestions please let me know !!
Looking forward to your reply!
Best,
Petros
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583391.html
Thanks for your prompt reply !
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 ) and finally now a second wrapper that I am writing that aims to bring
all these parts together ...
> How did you get it to compile?
during runtime in any attempt to instantiate an openFrameworks object, by
throwing a GLXWindow initialization error stating that no matching pixel
format was found ..
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.
So as I mentioned I narrowed it down to the specific check on the Eq side
if( !GLXEW_VERSION_1_3 && !GLXEW_SGIX_fbconfig ) { ... }
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..
>Do you want the two clients to render one output (scalability) or two
(powerwall)?
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
.)
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..
On the other hand if you have any other suggestions please let me know !!
Looking forward to your reply!
Best,
Petros
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583391.html
Stefan Eilemann
Jun 13, 2013, 2:56:23 AM6/13/13
to eq-...@equalizergraphics.com
Hi Petros,
On 11. Jun 2013, at 12:22, Petros.Kataras [via Software] <ml-node+s17...@n2.nabble.com> 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,
--
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583402.html
On 11. Jun 2013, at 12:22, Petros.Kataras [via Software] <ml-node+s17...@n2.nabble.com> 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 )
> 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.
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..
> 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 .)
> 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..
> On the other hand if you have any other suggestions please let me know !!
* 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,
--
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583402.html
Raimondo Giammanco
Jun 13, 2013, 3:03:18 AM6/13/13
to Equalizer Developer List, Stefan Eilemann
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
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
Petros.Kataras
Jun 18, 2013, 11:39:30 AM6/18/13
to eq-...@equalizergraphics.com
Hallo,
> How does it compare to Sequel? ANy chance of merging the two?
Its a GLUT-like wrapper that's based on Equalizer 1.0.2 and more
specifically the eqPly example. It provides a very simple interface so you
dont have to get into all the details of this amazing but quite complex
framework thats called..Equalizer ! :)
It has worked well in the past for realtime interactive graphics on various
sized clusters..
For me what I find really nice about this wrapper is that by reading a page
of documentation you can start working with it .. This is quite important I
think for production environments where multiple developers might have to
work on an Eq based app but not necessary have the time to get on all the
eq-related hardcore details ...
On the other hand the wrapper is not bullet-proof ( the handling of on app
instance with mutliple windows for example is not working properly which I
suspect might have something to do with context sharing and so on but havent
got to the bottom of this ) so for me ideally this wrapper should be adapted
in the future on top / merged of / with Sequel somehow..
Now I ve experimented a bit with Sequel and I would really like to see some
of the functionalites of the wrapper in there on the other hand..
Most importantly I think an interface / object manager to add - update -
remove shared objects as easy as possible ..
In our case this is as easy as extending a SharedObject class and calling
AddSharedObject(this) , UpdateSharedObject(this), RemoveSharedObject(this)
on the objects you want to distribute with the only need to define a
serialize / deserialize funtion...
When dealing with realtime interactive multimedia applications where you
have to update a lot of stuff actually something like this comes really
handy I think...
This is actually something that I could maybe help somehow -- Although I
would have to admit that there are times that Equalizer internals are kind
of really challenging to grasp so I suppose I would probably need some
guidance from you on this side ..
I would really like to have your opinion on this matter..i.e equalizer as a
multimedia - realtime - visualization framework and what would be your
approach on making the entry a bit easier on this kind of domain...
As for the pixel coordinate thing you are right and actually I was thinking
of what would be the best / correct way of dealing with 2D stuff in an easy
way and applyScreenFrustum does actually exactly what I need so thank you
for the info..
--
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583437.html
> How does it compare to Sequel? ANy chance of merging the two?
specifically the eqPly example. It provides a very simple interface so you
dont have to get into all the details of this amazing but quite complex
framework thats called..Equalizer ! :)
It has worked well in the past for realtime interactive graphics on various
sized clusters..
For me what I find really nice about this wrapper is that by reading a page
of documentation you can start working with it .. This is quite important I
think for production environments where multiple developers might have to
work on an Eq based app but not necessary have the time to get on all the
eq-related hardcore details ...
On the other hand the wrapper is not bullet-proof ( the handling of on app
instance with mutliple windows for example is not working properly which I
suspect might have something to do with context sharing and so on but havent
got to the bottom of this ) so for me ideally this wrapper should be adapted
in the future on top / merged of / with Sequel somehow..
Now I ve experimented a bit with Sequel and I would really like to see some
of the functionalites of the wrapper in there on the other hand..
Most importantly I think an interface / object manager to add - update -
remove shared objects as easy as possible ..
In our case this is as easy as extending a SharedObject class and calling
AddSharedObject(this) , UpdateSharedObject(this), RemoveSharedObject(this)
on the objects you want to distribute with the only need to define a
serialize / deserialize funtion...
When dealing with realtime interactive multimedia applications where you
have to update a lot of stuff actually something like this comes really
handy I think...
This is actually something that I could maybe help somehow -- Although I
would have to admit that there are times that Equalizer internals are kind
of really challenging to grasp so I suppose I would probably need some
guidance from you on this side ..
I would really like to have your opinion on this matter..i.e equalizer as a
multimedia - realtime - visualization framework and what would be your
approach on making the entry a bit easier on this kind of domain...
As for the pixel coordinate thing you are right and actually I was thinking
of what would be the best / correct way of dealing with 2D stuff in an easy
way and applyScreenFrustum does actually exactly what I need so thank you
for the info..
--
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583437.html
Stefan Eilemann
Jun 18, 2013, 11:54:20 AM6/18/13
to eq-...@equalizergraphics.com
Hi,
On 18. Jun 2013, at 17:39, Petros.Kataras [via Software] <ml-node+s171...@n2.nabble.com> wrote:
> Its a GLUT-like wrapper that's based on Equalizer 1.0.2 and more specifically the eqPly example. It provides a very simple interface so you dont have to get into all the details of this amazing but quite complex framework thats called..Equalizer ! :)
> It has worked well in the past for realtime interactive graphics on various sized clusters..
>
> For me what I find really nice about this wrapper is that by reading a page of documentation you can start working with it .. This is quite important I think for production environments where multiple developers might have to work on an Eq based app but not necessary have the time to get on all the eq-related hardcore details ...
I fully agree, and this has lead to Sequel which only has an Application and a Renderer class: http://eyescale.github.io/Equalizer-1.4/namespaceseq.html
> Most importantly I think an interface / object manager to add - update - remove shared objects as easy as possible ..
This is the idea behind Renderer and Application implementing co::ObjectFactory and using co::ObjectMap to add/update/remove shared object -- which I just realize is not exposed through the API in Sequel, even though the init and frame data objects are managed through this mechanism. Have a look at the aforementioned classes, and I'm happy to figure out an API to expose the ObjectMap API.
> In our case this is as easy as extending a SharedObject class and calling AddSharedObject(this) , UpdateSharedObject(this), RemoveSharedObject(this) on the objects you want to distribute with the only need to define a serialize / deserialize funtion...
>
> When dealing with realtime interactive multimedia applications where you have to update a lot of stuff actually something like this comes really handy I think...
We're in full agreement here.
> This is actually something that I could maybe help somehow -- Although I would have to admit that there are times that Equalizer internals are kind of really challenging to grasp so I suppose I would probably need some guidance from you on this side ..
I'm happy to help - just ask ahead.
> I would really like to have your opinion on this matter..i.e equalizer as a multimedia - realtime - visualization framework and what would be your approach on making the entry a bit easier on this kind of domain...
I would like to move forward with Sequel using a concrete use case like yours to provide a stupidly simple API for 90% of the Equalizer features.
> As for the pixel coordinate thing you are right and actually I was thinking of what would be the best / correct way of dealing with 2D stuff in an easy way and applyScreenFrustum does actually exactly what I need so thank you for the info..
Nice :)
Cheers,
Stefan.
--
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583438.html
On 18. Jun 2013, at 17:39, Petros.Kataras [via Software] <ml-node+s171...@n2.nabble.com> wrote:
> Its a GLUT-like wrapper that's based on Equalizer 1.0.2 and more specifically the eqPly example. It provides a very simple interface so you dont have to get into all the details of this amazing but quite complex framework thats called..Equalizer ! :)
> It has worked well in the past for realtime interactive graphics on various sized clusters..
>
> For me what I find really nice about this wrapper is that by reading a page of documentation you can start working with it .. This is quite important I think for production environments where multiple developers might have to work on an Eq based app but not necessary have the time to get on all the eq-related hardcore details ...
> Most importantly I think an interface / object manager to add - update - remove shared objects as easy as possible ..
> In our case this is as easy as extending a SharedObject class and calling AddSharedObject(this) , UpdateSharedObject(this), RemoveSharedObject(this) on the objects you want to distribute with the only need to define a serialize / deserialize funtion...
>
> When dealing with realtime interactive multimedia applications where you have to update a lot of stuff actually something like this comes really handy I think...
> This is actually something that I could maybe help somehow -- Although I would have to admit that there are times that Equalizer internals are kind of really challenging to grasp so I suppose I would probably need some guidance from you on this side ..
> I would really like to have your opinion on this matter..i.e equalizer as a multimedia - realtime - visualization framework and what would be your approach on making the entry a bit easier on this kind of domain...
> As for the pixel coordinate thing you are right and actually I was thinking of what would be the best / correct way of dealing with 2D stuff in an easy way and applyScreenFrustum does actually exactly what I need so thank you for the info..
Cheers,
Stefan.
--
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583438.html
Petros.Kataras
Jun 18, 2013, 12:40:14 PM6/18/13
to eq-...@equalizergraphics.com
> This is the idea behind Renderer and Application implementing
co::ObjectFactory and using co::ObjectMap to add/update/remove shared object
-- which I just realize is not exposed through the API in Sequel, even
though the init and frame data objects are managed through this mechanism.
Have a look at the aforementioned classes, and I'm happy to figure out an
API to expose the ObjectMap API.
Yes yes... I actually had a look a while ago playing around with seq and I
co::ObjectFactory and using co::ObjectMap to add/update/remove shared object
-- which I just realize is not exposed through the API in Sequel, even
though the init and frame data objects are managed through this mechanism.
Have a look at the aforementioned classes, and I'm happy to figure out an
API to expose the ObjectMap API.
also realized that this would be the way to go i.e trying to expose this
ObjectMap API somehow so good to know that we are on the same page :)
>I'm happy to help - just ask ahead.
>I would like to move forward with Sequel using a concrete use case like
yours to provide a stupidly simple API for 90% of the Equalizer features.
believe there is a huge potential for various Eq use cases ..
I ll be away from office for the next 2 weeks but I am getting back to you
as soon as I return..
--
View this message in context: http://software.1713.n2.nabble.com/Pixel-Coordinates-configuration-file-OF-Equalizer-tp7583381p7583439.html
Reply all
Reply to author
Forward
0 new messages