[eq-dev] Communicating information FROM the rendering code to the application logic?
8 views
Skip to first unread message
cpapado
Apr 25, 2014, 2:02:22 AM4/25/14
to eq-...@equalizergraphics.com
Hello everyone,
I've got a higher level question that came up as I am reengineering parts of
my application. Consider the following scenario:
Basic eq::Config driving a 3d viewer application, handling event management,
affecting render state but NOT including a copy of the scene graph
Scenegraph (for example OSG), with individual copies living within
eq::Window (since this provides "transparent" GPU resource duplication for
individual OpenGL contexts, especially in my usage scenario where 1 window =
1 GPU).
Single distributed frame data object for render state, camera position, etc
At each frame, the scene graph calculates clipping planes for the scene that
I'd like to distribute to the render nodes so that the visuals are
consistent. From my experience with EQ, I can figure out the following ways
to distribute that information:
1) The Config grabs the AppNode pointer, grabs its Pipe, then the Window and
gets the scene-graph related information that way. Am I correct to assume
that there needs to be synchronization here or does the AppNode's rendering
run on the same thread as the Config?
2) Every Node checks to see if it is the AppNode and the correct one
distributes the relevant information through the shared frame data object.
This would necessitate that the Config actually syncs changes to the shared
FrameData object rather than just assume that it is always holding the
master copy.
3) Similar to above, every Node checks to see if it is the AppNode and the
correct one grabs the clipping plane information and then sends it back to
the Config via a custom message.
Similar scenarios come up every time one needs to communicate between the
application logic and the scene graph (for example, when doing a ray-scene
intersection upon clicking the mouse, the coordinates need to be sent to the
scene graph and the resulting intersection communicated back to the
app-node).
What is the recommended programming pattern for accomplishing something like
this?
Thanks :)
-Harris
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385.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
I've got a higher level question that came up as I am reengineering parts of
my application. Consider the following scenario:
Basic eq::Config driving a 3d viewer application, handling event management,
affecting render state but NOT including a copy of the scene graph
Scenegraph (for example OSG), with individual copies living within
eq::Window (since this provides "transparent" GPU resource duplication for
individual OpenGL contexts, especially in my usage scenario where 1 window =
1 GPU).
Single distributed frame data object for render state, camera position, etc
At each frame, the scene graph calculates clipping planes for the scene that
I'd like to distribute to the render nodes so that the visuals are
consistent. From my experience with EQ, I can figure out the following ways
to distribute that information:
1) The Config grabs the AppNode pointer, grabs its Pipe, then the Window and
gets the scene-graph related information that way. Am I correct to assume
that there needs to be synchronization here or does the AppNode's rendering
run on the same thread as the Config?
2) Every Node checks to see if it is the AppNode and the correct one
distributes the relevant information through the shared frame data object.
This would necessitate that the Config actually syncs changes to the shared
FrameData object rather than just assume that it is always holding the
master copy.
3) Similar to above, every Node checks to see if it is the AppNode and the
correct one grabs the clipping plane information and then sends it back to
the Config via a custom message.
Similar scenarios come up every time one needs to communicate between the
application logic and the scene graph (for example, when doing a ray-scene
intersection upon clicking the mouse, the coordinates need to be sent to the
scene graph and the resulting intersection communicated back to the
app-node).
What is the recommended programming pattern for accomplishing something like
this?
Thanks :)
-Harris
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385.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
Apr 25, 2014, 3:48:26 AM4/25/14
to Equalizer Developer List
Hi Harris,
On 25. Apr 2014, at 8:02, cpapado <cpapad...@cs.sunysb.edu> wrote:
> At each frame, the scene graph calculates clipping planes for the scene that
> I'd like to distribute to the render nodes so that the visuals are
> consistent. From my experience with EQ, I can figure out the following ways
> to distribute that information:
>
> 1) The Config grabs the AppNode pointer, grabs its Pipe, then the Window and
> gets the scene-graph related information that way. Am I correct to assume
> that there needs to be synchronization here or does the AppNode's rendering
> run on the same thread as the Config?
Yes, the render threads are distinct from the main (node/config) thread. You are not guaranteed to have a render thread on the appNode. Depending on your thread model, you are however guaranteed to have a quiet time between frameFinish()...frameStart().
> 2) Every Node checks to see if it is the AppNode and the correct one
> distributes the relevant information through the shared frame data object.
> This would necessitate that the Config actually syncs changes to the shared
> FrameData object rather than just assume that it is always holding the
> master copy.
Yes, I recommend either using events for this back channel or reading the chapter on slave object commits carefully.
4) Each node calculates the clipping plane independently using an algorithm which derives the same result on all nodes
5) The application main thread has an (potentially incomplete) copy of the scene graph, calculates and distributes the information. All nodes sync it to their version.
HTH,
Stefan.
On 25. Apr 2014, at 8:02, cpapado <cpapad...@cs.sunysb.edu> wrote:
> At each frame, the scene graph calculates clipping planes for the scene that
> I'd like to distribute to the render nodes so that the visuals are
> consistent. From my experience with EQ, I can figure out the following ways
> to distribute that information:
>
> 1) The Config grabs the AppNode pointer, grabs its Pipe, then the Window and
> gets the scene-graph related information that way. Am I correct to assume
> that there needs to be synchronization here or does the AppNode's rendering
> run on the same thread as the Config?
> 2) Every Node checks to see if it is the AppNode and the correct one
> distributes the relevant information through the shared frame data object.
> This would necessitate that the Config actually syncs changes to the shared
> FrameData object rather than just assume that it is always holding the
> master copy.
>
> 3) Similar to above, every Node checks to see if it is the AppNode and the
> correct one grabs the clipping plane information and then sends it back to
> the Config via a custom message.
This one seems to be the cleanest so far. What about:
> 3) Similar to above, every Node checks to see if it is the AppNode and the
> correct one grabs the clipping plane information and then sends it back to
> the Config via a custom message.
4) Each node calculates the clipping plane independently using an algorithm which derives the same result on all nodes
5) The application main thread has an (potentially incomplete) copy of the scene graph, calculates and distributes the information. All nodes sync it to their version.
HTH,
Stefan.
cpapado
Apr 25, 2014, 6:24:55 AM4/25/14
to eq-...@equalizergraphics.com
Thank you for the reply Stefan!
To give you a bit more background, one of our projects seems to benefit a
lot of osgEarth so I am looking into integrating OpenSceneGraph to our
application (in fact, I already got a simple osgViewer-based integration
working). What would be very nice is to be able to use things like OSG
manipulators within an EQ application (especially for the osgEarth use case,
since traditional 6-DOF manipulation really doesn't work well).
My main concern with keeping a local copy of the scene graph in the config's
main thread is the "threat" of random OpenGL calls happening without the
presence of an OpenGL context. Now, my understanding is that OSG doesn't
really do that without an explicit request for a frame, but it still feels a
bit "dirty" from a software engineering perspective to duplicate a piece of
information that exists on the same machine and in the same process if there
is a way to cleanly get access to it without hamstringing EQ's performance.
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585388.html
To give you a bit more background, one of our projects seems to benefit a
lot of osgEarth so I am looking into integrating OpenSceneGraph to our
application (in fact, I already got a simple osgViewer-based integration
working). What would be very nice is to be able to use things like OSG
manipulators within an EQ application (especially for the osgEarth use case,
since traditional 6-DOF manipulation really doesn't work well).
My main concern with keeping a local copy of the scene graph in the config's
main thread is the "threat" of random OpenGL calls happening without the
presence of an OpenGL context. Now, my understanding is that OSG doesn't
really do that without an explicit request for a frame, but it still feels a
bit "dirty" from a software engineering perspective to duplicate a piece of
information that exists on the same machine and in the same process if there
is a way to cleanly get access to it without hamstringing EQ's performance.
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585388.html
Stefan Eilemann
Apr 25, 2014, 6:47:57 AM4/25/14
to eq-...@equalizergraphics.com
On 25. Apr 2014, at 12:24, "cpapado [via Software]" <ml-node+s171...@n2.nabble.com> wrote:
> My main concern with keeping a local copy of the scene graph in the config's main thread is the "threat" of random OpenGL calls happening without the presence of an OpenGL context. Now, my understanding is that OSG doesn't really do that without an explicit request for a frame, but it still feels a bit "dirty" from a software engineering perspective to duplicate a piece of information that exists on the same machine and in the same process if there is a way to cleanly get access to it without hamstringing EQ's performance.
In draw_sync, frameFinish is only unlocked after your local Channel::frameDraw are completed, therefore you can modify the manipulator in handleEvents without locking. Using the Config to store and lazy load the SG would then even work for appNodes without a pipe render thread, and no duplication does occur when its not needed.
HTH,
Stefan.
--
http://www.eyescale.ch
https://github.com/Eyescale/
http://www.linkedin.com/in/eilemann
signature.asc (858 bytes) <http://software.1713.n2.nabble.com/attachment/7585389/0/signature.asc>
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585389.html
Dardo D Kleiner - CONTRACTOR
Apr 25, 2014, 7:58:40 AM4/25/14
to Equalizer Developer List
I've gone down this path - namely osgEarth in Equalizer. It gets a bit tricky, and I'm not happy with what I've got so far but it kinda works (and looks great on a 4x3 2560x1600 tile wall).
One problem is that in order for the EarthManipulator to work, it needs a full copy of the SG (at least one with the elevation data, e.g. for world picking). At least two choices here:
You could have the manipulator installed on all nodes and figure out which one is "authoritative" and send eq::Config mouse events there.
Or you have the manipulator installed only on the appNode, but if you have the SG in the appNode, and it doesn't have a render thread - it needs a "fake" render thread in order to update the scene graph so the manipulator can do its thing.
I've hacked a scheme whereby if the appNode doesn't have a render thread, it runs an OSG pbuffer context offscreen and mouse events are sent to an attached osg viewer. Then the osg::camera matrix is extracted from the manipulator and sent out in the eq::View to all the render nodes.
osgEarth requires a capable GL context, so this means the appNode has to have a GPU - but it doesn't have to be a destination channel.
I even play games such that if the appNode *does* have an eq render thread, this offscreen context is not used and it just uses the real context attached to the destination channel. But its still ugly, e.g. it has to change the viewport to the entire scene in order to, e.g., translate mouse events properly.
If osgEarth's SG could be serialized, then it could be much more like eqPly. But for now I just have every eq node run a full OSG instance on all of its defined pipes.
I'd love to see what you come up with, Harris. I'd even share what I have if you're interested, understanding that its a bit of a mess. Its been a while since I was neck deep in the details, there were a bunch of other gotchas if I recall (like osgEarth creating its own GL contexts before Eq got fully started).
- Dardo
On 04/25/2014 06:47 AM, Stefan Eilemann wrote:
>
> On 25. Apr 2014, at 12:24, "cpapado [via Software]" <ml-node+s171...@n2.nabble.com> wrote:
>
>> My main concern with keeping a local copy of the scene graph in the config's main thread is the "threat" of random OpenGL calls happening without the presence of an OpenGL context. Now, my understanding is that OSG doesn't really do that without an explicit request for a frame, but it still feels a bit "dirty" from a software engineering perspective to duplicate a piece of information that exists on the same machine and in the same process if there is a way to cleanly get access to it without hamstringing EQ's performance.
>
> You could use the same copy of the SG if you use the default draw_sync threading model. The copy would then be maintained by the config, and only the lazy-load access method needs to be locked. eqPly uses a similar model, although with a static "SG" and async thread model.
>
> In draw_sync, frameFinish is only unlocked after your local Channel::frameDraw are completed, therefore you can modify the manipulator in handleEvents without locking. Using the Config to store and lazy load the SG would then even work for appNodes without a pipe render thread, and no duplication does occur when its not needed.
>
>
> HTH,
>
> Stefan.
>
One problem is that in order for the EarthManipulator to work, it needs a full copy of the SG (at least one with the elevation data, e.g. for world picking). At least two choices here:
You could have the manipulator installed on all nodes and figure out which one is "authoritative" and send eq::Config mouse events there.
Or you have the manipulator installed only on the appNode, but if you have the SG in the appNode, and it doesn't have a render thread - it needs a "fake" render thread in order to update the scene graph so the manipulator can do its thing.
I've hacked a scheme whereby if the appNode doesn't have a render thread, it runs an OSG pbuffer context offscreen and mouse events are sent to an attached osg viewer. Then the osg::camera matrix is extracted from the manipulator and sent out in the eq::View to all the render nodes.
osgEarth requires a capable GL context, so this means the appNode has to have a GPU - but it doesn't have to be a destination channel.
I even play games such that if the appNode *does* have an eq render thread, this offscreen context is not used and it just uses the real context attached to the destination channel. But its still ugly, e.g. it has to change the viewport to the entire scene in order to, e.g., translate mouse events properly.
If osgEarth's SG could be serialized, then it could be much more like eqPly. But for now I just have every eq node run a full OSG instance on all of its defined pipes.
I'd love to see what you come up with, Harris. I'd even share what I have if you're interested, understanding that its a bit of a mess. Its been a while since I was neck deep in the details, there were a bunch of other gotchas if I recall (like osgEarth creating its own GL contexts before Eq got fully started).
- Dardo
On 04/25/2014 06:47 AM, Stefan Eilemann wrote:
>
> On 25. Apr 2014, at 12:24, "cpapado [via Software]" <ml-node+s171...@n2.nabble.com> wrote:
>
>> My main concern with keeping a local copy of the scene graph in the config's main thread is the "threat" of random OpenGL calls happening without the presence of an OpenGL context. Now, my understanding is that OSG doesn't really do that without an explicit request for a frame, but it still feels a bit "dirty" from a software engineering perspective to duplicate a piece of information that exists on the same machine and in the same process if there is a way to cleanly get access to it without hamstringing EQ's performance.
>
> You could use the same copy of the SG if you use the default draw_sync threading model. The copy would then be maintained by the config, and only the lazy-load access method needs to be locked. eqPly uses a similar model, although with a static "SG" and async thread model.
>
> In draw_sync, frameFinish is only unlocked after your local Channel::frameDraw are completed, therefore you can modify the manipulator in handleEvents without locking. Using the Config to store and lazy load the SG would then even work for appNodes without a pipe render thread, and no duplication does occur when its not needed.
>
>
> HTH,
>
> Stefan.
>
cpapado
Apr 25, 2014, 8:25:14 AM4/25/14
to eq-...@equalizergraphics.com
Hello Dardo!
Glad to see that there is someone sharing the pain :). Thank you for the
very detailed response.
I don't like the "one manipulator per render node" solution that much. It
requires both forwarding all the events to every render node and also
communicating the changes to camera position/orientation back to the head
node so that those get pushed to all the render nodes again for the actual
rendering. It basically breaks the clean separation between application
logic and application view that EQ has.
The second solution that you and Stephan described seems more appropriate.
Also, you bring up a very valid point of osgEarth requiring the existence of
an OpenGL context. I fought that issue when putting my current integration
together. Basically the reason why osgEarth requires (and actually tries to
spawn) an OpenGL context is so that it can query for OpenGL capabilities. It
is also not particularly clean when it does so I think (it doesn't restore
the previously bound context) and it offers no direct way to "disable" the
capability querying. The way I worked around it in my software (which uses
osgViewer with a graphicsWindowEmbedded on each eq::Window) is by actually
overriding the default OSG GraphicsContext with a stub implementation that
basically does nothing. This way, when osgEarth tries to query for
capabilities, it does so within the existing OpenGL context that has been
graciously provided by Equalizer. Other than this point, the rest of my
implementation is pretty standard (single distributed object for the camera
state + other rendering parameters, all interactions are handled at the app
node) but as I mentioned, this doesn't work that well with osgEarth since I
can't directly use it with EarthManipulator.
I'd love to see how you tackled this issue (accessing the render thread's gl
context from within the Config main loop in a safe way, I would be happy
with that solution since I always run the app node in head-full mode). I can
share my implementation with you as well (with the same caveat of it being
very dirty code at the moment :P), but as I mentioned, it is not
particularly complex.
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585391.html
Glad to see that there is someone sharing the pain :). Thank you for the
very detailed response.
I don't like the "one manipulator per render node" solution that much. It
requires both forwarding all the events to every render node and also
communicating the changes to camera position/orientation back to the head
node so that those get pushed to all the render nodes again for the actual
rendering. It basically breaks the clean separation between application
logic and application view that EQ has.
The second solution that you and Stephan described seems more appropriate.
Also, you bring up a very valid point of osgEarth requiring the existence of
an OpenGL context. I fought that issue when putting my current integration
together. Basically the reason why osgEarth requires (and actually tries to
spawn) an OpenGL context is so that it can query for OpenGL capabilities. It
is also not particularly clean when it does so I think (it doesn't restore
the previously bound context) and it offers no direct way to "disable" the
capability querying. The way I worked around it in my software (which uses
osgViewer with a graphicsWindowEmbedded on each eq::Window) is by actually
overriding the default OSG GraphicsContext with a stub implementation that
basically does nothing. This way, when osgEarth tries to query for
capabilities, it does so within the existing OpenGL context that has been
graciously provided by Equalizer. Other than this point, the rest of my
implementation is pretty standard (single distributed object for the camera
state + other rendering parameters, all interactions are handled at the app
node) but as I mentioned, this doesn't work that well with osgEarth since I
can't directly use it with EarthManipulator.
I'd love to see how you tackled this issue (accessing the render thread's gl
context from within the Config main loop in a safe way, I would be happy
with that solution since I always run the app node in head-full mode). I can
share my implementation with you as well (with the same caveat of it being
very dirty code at the moment :P), but as I mentioned, it is not
particularly complex.
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585391.html
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
Dardo D Kleiner - CONTRACTOR
Apr 28, 2014, 7:36:54 AM4/28/14
to eq-...@equalizergraphics.com
https://github.com/dardok/eqEarth
Very dirty, some stuff broken in recent hacks to get up to latest Equalizer & osgEarth.
Lots of ifdef's trying different stuff. Totally broken 2d overlay attempts, various picking attempts, config manipulation attempts, etc. No real build system, just a site-specific Makefile.
Kinda works though.
- Dardo
Very dirty, some stuff broken in recent hacks to get up to latest Equalizer & osgEarth.
Lots of ifdef's trying different stuff. Totally broken 2d overlay attempts, various picking attempts, config manipulation attempts, etc. No real build system, just a site-specific Makefile.
Kinda works though.
- Dardo
cpapado
Apr 30, 2014, 12:55:06 AM4/30/14
to eq-...@equalizergraphics.com
Thanks Dardo, I wanna go through this in detail and I'll get back to you with
some comments :).
Stefan, as I am working through this, I am wondering the following. What is
the proper way to use the new co::CustomI/OCommand system to get this type
of back-and-forth communication going between a render node (at whatever
level, Window, Channel, Node, etc) and the main config?
I've been going through EQ's source code and it seems that everything is
handled by sending messages directly to the server node. i'm a bit fuzzy on
how messages are routed past that point. How would I go about:
a) Transmitting a custom command from the application node to all render
nodes
b) Transmitting a custom command from a single render node back to the
application node
For (b) it seems that through the config I can get a pointer to the
application node through an experimental API (co::NodePtr
getApplicationNode()). Is this safe to do so? Is the proper way to achieve
(a) just sending the message to the Server?
Thanks!
-Harris
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585415.html
some comments :).
Stefan, as I am working through this, I am wondering the following. What is
the proper way to use the new co::CustomI/OCommand system to get this type
of back-and-forth communication going between a render node (at whatever
level, Window, Channel, Node, etc) and the main config?
I've been going through EQ's source code and it seems that everything is
handled by sending messages directly to the server node. i'm a bit fuzzy on
how messages are routed past that point. How would I go about:
a) Transmitting a custom command from the application node to all render
nodes
b) Transmitting a custom command from a single render node back to the
application node
For (b) it seems that through the config I can get a pointer to the
application node through an experimental API (co::NodePtr
getApplicationNode()). Is this safe to do so? Is the proper way to achieve
(a) just sending the message to the Server?
Thanks!
-Harris
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585415.html
Stefan Eilemann
Apr 30, 2014, 3:06:10 AM4/30/14
to eq-...@equalizergraphics.com
On 30. Apr 2014, at 6:55, cpapado [via Software] <ml-node+s171...@n2.nabble.com> wrote:
> I've been going through EQ's source code and it seems that everything is handled by sending messages directly to the server node.
> i'm a bit fuzzy on how messages are routed past that point. How would I go about:
> a) Transmitting a custom command from the application node to all render nodes
> b) Transmitting a custom command from a single render node back to the application node
>
> For (b) it seems that through the config I can get a pointer to the application node through an experimental API (co::NodePtr getApplicationNode()). Is this safe to do so? Is the proper way to achieve (a) just sending the message to the Server?
That said, getApplicationNode is safe to use for b). The other way is a bit more complex. LocalNode::getNodes() gets you all connected nodes, including the server and any potential other Collage entities (admin interface, other communicators). The safest way is probably sending an event from Node::configInit and configExit and let the application track this list itself.
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/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585416.html
cpapado
Apr 30, 2014, 12:33:10 PM4/30/14
to eq-...@equalizergraphics.com
Thank you for the very thorough reply Stefan!
Stefan Eilemann wrote
effect of sending a message to the server node? Does it automatically get
pushed to basically ALL nodes in the collage session?
Stefan Eilemann wrote
remote nodes, receive on the application node and keep track of node list),
is it safe to cache the pointers returned by getRemoteNode() (will they
stick around during the application session)? Or should I cache node IDs and
request new node pointers every time I need to push a message?
Cheers,
Harris
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585418.html
Stefan Eilemann wrote
> Not everything. Object map requests often go to the application thread
> (Framedata, ...), and so do events.
Yeah you're right, it was more of a blanket statement. However, what is the
> (Framedata, ...), and so do events.
effect of sending a message to the server node? Does it automatically get
pushed to basically ALL nodes in the collage session?
Stefan Eilemann wrote
> That said, getApplicationNode is safe to use for b). The other way is a
> bit more complex. LocalNode::getNodes() gets you all connected nodes,
> including the server and any potential other Collage entities (admin
> interface, other communicators). The safest way is probably sending an
> event from Node::configInit and configExit and let the application track
> this list itself.
If I were to utilize this approach, (sendEvent via the Config from the
> bit more complex. LocalNode::getNodes() gets you all connected nodes,
> including the server and any potential other Collage entities (admin
> interface, other communicators). The safest way is probably sending an
> event from Node::configInit and configExit and let the application track
> this list itself.
remote nodes, receive on the application node and keep track of node list),
is it safe to cache the pointers returned by getRemoteNode() (will they
stick around during the application session)? Or should I cache node IDs and
request new node pointers every time I need to push a message?
Cheers,
Harris
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585418.html
Stefan Eilemann
May 1, 2014, 3:36:02 AM5/1/14
to eq-...@equalizergraphics.com
On 30. Apr 2014, at 18:33, cpapado [via Software] <ml-node+s171...@n2.nabble.com> wrote:
> Yeah you're right, it was more of a blanket statement. However, what is the effect of sending a message to the server node? Does it automatically get pushed to basically ALL nodes in the collage session?
> If I were to utilize this approach, (sendEvent via the Config from the remote nodes, receive on the application node and keep track of node list), is it safe to cache the pointers returned by getRemoteNode() (will they stick around during the application session)? Or should I cache node IDs and request new node pointers every time I need to push a message?
HTH,
Stefan.
signature.asc (858 bytes) <http://software.1713.n2.nabble.com/attachment/7585419/0/signature.asc>
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585419.html
cpapado
May 5, 2014, 12:26:25 AM5/5/14
to eq-...@equalizergraphics.com
Thanks for the response Stefan, I implemented an approach the way you
describe (with nodes registered themselves on configInit and then Collage
custom commands are send to them).
I'm also trying to implement the opposite channel of communication (from a
render node back to the main app node). My current implementation utilizes
collage custom commands. If I want to utilize the same command id for for
bidirectional communication on the app node (from the window or pipe level
back to the config for example) I run into an issue where I try to register
two different command handlers on one local node for the same command ID. So
i thought I would try to use co::Object messaging instead.
However, I am not able to figure out how to send the same message to
multiple co::Object instances simultaneously. The API that I am seeing
(co::Object::send()) only allows for sending a message to a single instance
(or all instances) of an Object on a single node. Is there a way to do
"multi-cast" node sending (basically generating an ObjectOCommand with
multiple object instances on multiple nodes are the recipients)?
Cheers,
Harris
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585442.html
describe (with nodes registered themselves on configInit and then Collage
custom commands are send to them).
I'm also trying to implement the opposite channel of communication (from a
render node back to the main app node). My current implementation utilizes
collage custom commands. If I want to utilize the same command id for for
bidirectional communication on the app node (from the window or pipe level
back to the config for example) I run into an issue where I try to register
two different command handlers on one local node for the same command ID. So
i thought I would try to use co::Object messaging instead.
However, I am not able to figure out how to send the same message to
multiple co::Object instances simultaneously. The API that I am seeing
(co::Object::send()) only allows for sending a message to a single instance
(or all instances) of an Object on a single node. Is there a way to do
"multi-cast" node sending (basically generating an ObjectOCommand with
multiple object instances on multiple nodes are the recipients)?
Cheers,
Harris
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585442.html
Stefan Eilemann
May 5, 2014, 2:07:26 AM5/5/14
to Equalizer Developer List
On 5. May 2014, at 6:26, cpapado <cpapad...@cs.sunysb.edu> wrote:
> I'm also trying to implement the opposite channel of communication (from a
> render node back to the main app node). My current implementation utilizes
> collage custom commands. If I want to utilize the same command id for for
> bidirectional communication on the app node (from the window or pipe level
> back to the config for example) I run into an issue where I try to register
> two different command handlers on one local node for the same command ID.
> So
> i thought I would try to use co::Object messaging instead.
> However, I am not able to figure out how to send the same message to
> multiple co::Object instances simultaneously. The API that I am seeing
> (co::Object::send()) only allows for sending a message to a single instance
> (or all instances) of an Object on a single node. Is there a way to do
> "multi-cast" node sending (basically generating an ObjectOCommand with
> multiple object instances on multiple nodes are the recipients)?
Cheers,
Stefan.
PS: Noticed your email address - are you working on the RealityDeck? I heard some rumours that you're using Equalizer and would love to see some pictures.
cpapado
May 5, 2014, 4:01:27 AM5/5/14
to eq-...@equalizergraphics.com
Stefan Eilemann wrote
> I guess nobody needed it so far. A send( nodes, cmd ) would be easy enough
> to implement. Please open a ticket if you still need it. If you feel up to
> it, a pull request with the implementation would be even better.
Judging from the source, it shouldn't be too hard. However, I'm stuck right
now with Collage blowing up on the Receiver thread, after it dispatches to
object command to the handler function. EXC_BAD_ACCESS with the following
stack trace:
rame #0: 0x0000000104b069d0
frame #1: 0x00000001003b7db8
libCollage.110.dylib`co::Dispatcher::dispatchCommand(co::ICommand&) + 104
frame #2: 0x00000001003f30bc
libCollage.110.dylib`co::ObjectStore::dispatchObjectCommand(co::ICommand&) +
300
frame #3: 0x00000001003d0d29
libCollage.110.dylib`co::LocalNode::dispatchCommand(co::ICommand&) + 57
frame #4: 0x000000010048da50
libEqualizerFabric.172.dylib`eq::fabric::Client::dispatchCommand(co::ICommand&)
+ 128
frame #5: 0x00000001003d0bca
libCollage.110.dylib`co::LocalNode::_dispatchCommand(co::ICommand&) + 26
frame #6: 0x00000001003cf674
libCollage.110.dylib`co::LocalNode::_handleData() + 596
frame #7: 0x00000001003cdef0
libCollage.110.dylib`co::LocalNode::_runReceiverThread() + 320
frame #8: 0x0000000100366c32
libLunchbox.190.dylib`lunchbox::Thread::_runChild() + 738
frame #9: 0x0000000100366949
libLunchbox.190.dylib`lunchbox::Thread::runChild(void*) + 9
frame #10: 0x00007fff8cdba899 libsystem_pthread.dylib`_pthread_body +
138
frame #11: 0x00007fff8cdba72a libsystem_pthread.dylib`_pthread_start +
137
This happens with and without specifying a custom handler for that
particular command...What is weirded is that the handler itself executes
fine (and I verified the relevant pointers as well), the exception happens
when getting back into the dispatchCommand function. I gotta investigate
more but it's 4:00am here in the US and its time to sleep :). If you have
any suggestions, I'd appreciate them!
> PS: Noticed your email address - are you working on the RealityDeck? I
> heard some rumours that you're using Equalizer and would love to see some
> pictures.
Yup :). One of our software stacks is EQ-based with different renderers on
top. Here's an early photo
http://labs.cs.sunysb.edu/labs/images/reality/applications/GIS.JPG of one of
our GIS renderers that runs on top of EQ.
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585444.html
> Why so complicated? You could either use a different command id (+1, or a
> new UUID) or Config::sendEvent.
Personal preference + an exercise in getting familiar with Collage.
> new UUID) or Config::sendEvent.
> I guess nobody needed it so far. A send( nodes, cmd ) would be easy enough
> to implement. Please open a ticket if you still need it. If you feel up to
> it, a pull request with the implementation would be even better.
now with Collage blowing up on the Receiver thread, after it dispatches to
object command to the handler function. EXC_BAD_ACCESS with the following
stack trace:
rame #0: 0x0000000104b069d0
frame #1: 0x00000001003b7db8
libCollage.110.dylib`co::Dispatcher::dispatchCommand(co::ICommand&) + 104
frame #2: 0x00000001003f30bc
libCollage.110.dylib`co::ObjectStore::dispatchObjectCommand(co::ICommand&) +
300
frame #3: 0x00000001003d0d29
libCollage.110.dylib`co::LocalNode::dispatchCommand(co::ICommand&) + 57
frame #4: 0x000000010048da50
libEqualizerFabric.172.dylib`eq::fabric::Client::dispatchCommand(co::ICommand&)
+ 128
frame #5: 0x00000001003d0bca
libCollage.110.dylib`co::LocalNode::_dispatchCommand(co::ICommand&) + 26
frame #6: 0x00000001003cf674
libCollage.110.dylib`co::LocalNode::_handleData() + 596
frame #7: 0x00000001003cdef0
libCollage.110.dylib`co::LocalNode::_runReceiverThread() + 320
frame #8: 0x0000000100366c32
libLunchbox.190.dylib`lunchbox::Thread::_runChild() + 738
frame #9: 0x0000000100366949
libLunchbox.190.dylib`lunchbox::Thread::runChild(void*) + 9
frame #10: 0x00007fff8cdba899 libsystem_pthread.dylib`_pthread_body +
138
frame #11: 0x00007fff8cdba72a libsystem_pthread.dylib`_pthread_start +
137
This happens with and without specifying a custom handler for that
particular command...What is weirded is that the handler itself executes
fine (and I verified the relevant pointers as well), the exception happens
when getting back into the dispatchCommand function. I gotta investigate
more but it's 4:00am here in the US and its time to sleep :). If you have
any suggestions, I'd appreciate them!
> PS: Noticed your email address - are you working on the RealityDeck? I
> heard some rumours that you're using Equalizer and would love to see some
> pictures.
top. Here's an early photo
http://labs.cs.sunysb.edu/labs/images/reality/applications/GIS.JPG of one of
our GIS renderers that runs on top of EQ.
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585444.html
Stefan Eilemann
May 5, 2014, 4:20:26 AM5/5/14
to eq-...@equalizergraphics.com
On 5. May 2014, at 10:01, "cpapado [via Software]" <ml-node+s171...@n2.nabble.com> wrote:
> Personal preference + an exercise in getting familiar with Collage.
> Judging from the source, it shouldn't be too hard. However, I'm stuck right now with Collage blowing up on the Receiver thread, after it dispatches to object command to the handler function. EXC_BAD_ACCESS with the following stack trace:
>
> rame #0: 0x0000000104b069d0
> frame #1: 0x00000001003b7db8 libCollage.110.dylib`co::Dispatcher::dispatchCommand(co::ICommand&) + 104
> frame #2: 0x00000001003f30bc libCollage.110.dylib`co::ObjectStore::dispatchObjectCommand(co::ICommand&) + 300
> frame #3: 0x00000001003d0d29 libCollage.110.dylib`co::LocalNode::dispatchCommand(co::ICommand&) + 57
> frame #4: 0x000000010048da50 libEqualizerFabric.172.dylib`eq::fabric::Client::dispatchCommand(co::ICommand&) + 128
> frame #5: 0x00000001003d0bca libCollage.110.dylib`co::LocalNode::_dispatchCommand(co::ICommand&) + 26
> frame #6: 0x00000001003cf674 libCollage.110.dylib`co::LocalNode::_handleData() + 596
> frame #7: 0x00000001003cdef0 libCollage.110.dylib`co::LocalNode::_runReceiverThread() + 320
> frame #8: 0x0000000100366c32 libLunchbox.190.dylib`lunchbox::Thread::_runChild() + 738
> frame #9: 0x0000000100366949 libLunchbox.190.dylib`lunchbox::Thread::runChild(void*) + 9
> frame #10: 0x00007fff8cdba899 libsystem_pthread.dylib`_pthread_body + 138
> frame #11: 0x00007fff8cdba72a libsystem_pthread.dylib`_pthread_start + 137
>
> This happens with and without specifying a custom handler for that particular command...What is weirded is that the handler itself executes fine (and I verified the relevant pointers as well), the exception happens when getting back into the dispatchCommand function. I gotta investigate more but it's 4:00am here in the US and its time to sleep :). If you have any suggestions, I'd appreciate them!
> Yup :). One of our software stacks is EQ-based with different renderers on top. Here's an early photo http://labs.cs.sunysb.edu/labs/images/reality/applications/GIS.JPG of one of our GIS renderers that runs on top of EQ.
Cheers,
Stefan.
signature.asc (858 bytes) <http://software.1713.n2.nabble.com/attachment/7585445/0/signature.asc>
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585445.html
cpapado
May 5, 2014, 4:35:01 AM5/5/14
to eq-...@equalizergraphics.com
Stefan Eilemann wrote
register a command handler at all...I'm fiddling with Xcode's stack smashing
guards now, maybe they'll give some more insight...Custom object commands
work fine in other pieces of code that I'm building with the same build
environment so I don't think it's an issue on that front...
Stefan Eilemann wrote
delighted to give you a tour. Are you going to Vis this year?
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585446.html
> Not really. From what you describe it looks like your stack gets
> corrupted, but I can't say why. I guess the customCommands unit test
> executes fine? Does it also crash if you do nothing in your command
> handler?
Yup, it crashes with an empty command handler and it crashes if I don't even
> corrupted, but I can't say why. I guess the customCommands unit test
> executes fine? Does it also crash if you do nothing in your command
> handler?
register a command handler at all...I'm fiddling with Xcode's stack smashing
guards now, maybe they'll give some more insight...Custom object commands
work fine in other pieces of code that I'm building with the same build
environment so I don't think it's an issue on that front...
Stefan Eilemann wrote
> Nice - I'ld like to hear more about your experiences at some point. Maybe
> we'll run across each other at a conference.
Fingers crossed :). If you're ever in NY, do shoot me an email, I'd be
> we'll run across each other at a conference.
delighted to give you a tour. Are you going to Vis this year?
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585446.html
cpapado
May 5, 2014, 3:09:44 PM5/5/14
to eq-...@equalizergraphics.com
This actually seems to be a problem with utilizing release collage/eq
binaries in a debug build of my application...switching my build to release
takes care of the problem and so does compiling Collage in debug mode.
Don't the build scripts allow to install both debug AND release binaries
simultaneously any more? I compiled and installed collage in debug mode but
the install script overwrites the existing .dylib (I know this wasn't
supported on windows but I recall it working in OSX before...).
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585458.html
binaries in a debug build of my application...switching my build to release
takes care of the problem and so does compiling Collage in debug mode.
Don't the build scripts allow to install both debug AND release binaries
simultaneously any more? I compiled and installed collage in debug mode but
the install script overwrites the existing .dylib (I know this wasn't
supported on windows but I recall it working in OSX before...).
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585458.html
Stefan Eilemann
May 5, 2014, 3:14:54 PM5/5/14
to eq-...@equalizergraphics.com
On 5. May 2014, at 21:09, cpapado [via Software] <ml-node+s171...@n2.nabble.com> wrote:
> This actually seems to be a problem with utilizing release collage/eq binaries in a debug build of my application...switching my build to release takes care of the problem and so does compiling Collage in debug mode.
>
> Don't the build scripts allow to install both debug AND release binaries simultaneously any more? I compiled and installed collage in debug mode but the install script overwrites the existing .dylib (I know this wasn't supported on windows but I recall it working in OSX before...).
Cheers,
Stefan.
signature.asc (858 bytes) <http://software.1713.n2.nabble.com/attachment/7585459/0/signature.asc>
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585459.html
cpapado
May 5, 2014, 3:17:27 PM5/5/14
to eq-...@equalizergraphics.com
I'm currently working on OSX actually. So I would have to build for debug,
then package, then install the package? Just running the install target for
a debug build just overwrites the dylib in /usr/lib.
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585460.html
then package, then install the package? Just running the install target for
a debug build just overwrites the dylib in /usr/lib.
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585460.html
Stefan Eilemann
May 5, 2014, 3:22:26 PM5/5/14
to eq-...@equalizergraphics.com
On 5. May 2014, at 21:17, "cpapado [via Software]" <ml-node+s171...@n2.nabble.com> wrote:
> I'm currently working on OSX actually. So I would have to build for debug, then package, then install the package? Just running the install target for a debug build just overwrites the dylib in /usr/lib.
We *should* actually package the debug libs into lib/debug, so that you can install the debug package concurrently with the release one. So far we've only build release packages since the developers needing debug symbols often just build from source.
Cheers,
Stefan.
signature.asc (858 bytes) <http://software.1713.n2.nabble.com/attachment/7585461/0/signature.asc>
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585461.html
cpapado
May 5, 2014, 3:30:15 PM5/5/14
to eq-...@equalizergraphics.com
I'm doing Xcode builds.
Have you every heard of release-debug mixing conflicts in OSX? I know it's
"a thing" with Microsoft's compiler/runtime, but I've never come across such
a problem in a Unix setting...
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585462.html
Have you every heard of release-debug mixing conflicts in OSX? I know it's
"a thing" with Microsoft's compiler/runtime, but I've never come across such
a problem in a Unix setting...
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585462.html
Stefan Eilemann
May 5, 2014, 3:35:02 PM5/5/14
to eq-...@equalizergraphics.com
On 5. May 2014, at 21:30, cpapado [via Software] <ml-node+s17...@n2.nabble.com> wrote:
> Have you every heard of release-debug mixing conflicts in OSX? I know it's "a thing" with Microsoft's compiler/runtime, but I've never come across such a problem in a Unix setting...
HTH,
Stefan.
signature.asc (858 bytes) <http://software.1713.n2.nabble.com/attachment/7585463/0/signature.asc>
--
View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585463.html
Reply all
Reply to author
Forward
0 new messages