Quantcast

Communicating information FROM the rendering code to the application logic?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Communicating information FROM the rendering code to the application logic?

cpapado
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

Stefan Eilemann
Hi Harris,

On 25. Apr 2014, at 8:02, cpapado <[hidden email]> 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.
>
> 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:

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.


_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

cpapado
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

Stefan Eilemann

On 25. Apr 2014, at 12:24, "cpapado [via Software]" <[hidden email]> 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.
--
http://www.eyescale.ch
https://github.com/Eyescale/
http://www.linkedin.com/in/eilemann





signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

Dardo
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]" <[hidden email]> 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.
>

_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

cpapado
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

Dardo
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

On 04/25/2014 08:25 AM, cpapado wrote:

> 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
> Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
>
> _______________________________________________
> eq-dev mailing list
> [hidden email]
> http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
> http://www.equalizergraphics.com
>
>

_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

cpapado
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

Stefan Eilemann

On 30. Apr 2014, at 6:55, cpapado [via Software] <[hidden email]> 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.

Not everything. Object map requests often go to the application thread (Framedata, ...), and so do events.

> 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?

We have not formalized a way to send commands in both directions. Obviously it is possible to do so. The formalized communication channels are the FrameData for a), which has the benefit of being latency-correct. For b), the formalized way is Config::sendEvent(). Any other way might change in future versions, but I am certain that we'll retain the functionality.

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





signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

cpapado
Thank you for the very thorough reply Stefan!

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 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 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

Stefan Eilemann

On 30. Apr 2014, at 18:33, cpapado [via Software] <[hidden email]> 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?

No, the commands send to the server are for the server to process, e.g., frameStart will be send to the server which then calculates all task commands for each render node.

> 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?

If you also unregister nodes upon Node::configExit, maintaining a list of nodes is fine. In any case, they are reference counted, so worst case you end up with a closed node in your vector.


HTH,

Stefan.


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

cpapado
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

Stefan Eilemann

On 5. May 2014, at 6:26, cpapado <[hidden email]> 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.

Correct, one for the 'to' channel to all render nodes, one for the 'back' channel from the local render node.

> So
> i thought I would try to use co::Object messaging instead.

Why so complicated? You could either use a different command id (+1, or a new UUID) or Config::sendEvent.

> 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)?

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.


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.
--
http://www.eyescale.ch
https://github.com/Eyescale/
http://www.linkedin.com/in/eilemann





_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

cpapado
Stefan Eilemann wrote
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.

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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

Stefan Eilemann

On 5. May 2014, at 10:01, "cpapado [via Software]" <[hidden email]> wrote:

> Personal preference + an exercise in getting familiar with Collage.

Good reason. :)

> 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!
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 :). 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.

Nice - I'ld like to hear more about your experiences at some point. Maybe we'll run across each other at a conference.


Cheers,

Stefan.


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

cpapado
Stefan Eilemann wrote
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 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 delighted to give you a tour. Are you going to Vis this year?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

cpapado
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...).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

Stefan Eilemann

On 5. May 2014, at 21:09, cpapado [via Software] <[hidden email]> 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...).

The Unix way of doing this is to install and build using different directories. That even trickles down to packages, which install to /usr/lib/debug. This way you can debug an application by simply tweaking your LD_LIBRARY_PATH. Not that VS could do that ever, thanks to its incompatible debug/release compilation...


Cheers,

Stefan.


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

cpapado
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Communicating information FROM the rendering code to the application logic?

Stefan Eilemann

On 5. May 2014, at 21:17, "cpapado [via Software]" <[hidden email]> 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.

XCode or Makefiles?

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) Download Attachment
12
Loading...