Hi Jonas
To handle the key or mouse events in eqOSG , in my implementation I have
collocted all the events in Config::handlEvent() in a vector list and
passed to the Pipe using frame data and converted these events in OSG
and set to the event queue of the osgViewer. You can get the event queue
of the osgViewer using function viewer->getEventQueue().
Hope this will help you ..
Santosh Gaikwad
MTS Design
Darshan Solutions Limited
www.darshan3d.com <http://www.darshan3d.com>
# +91-99530-99053
Stefan Eilemann wrote:
On 28. Apr 2009, at 0:21, Jonas Walti wrote:
Thomas McGuire schrieb
You could use Config::handleEvent() to translate Equalizer events
to OSG
events and add them to the EventQueue I guess. I'm not sure how you
can get
the EventQueue of the viewer. The viewer has a window, which is a
osgViewer::GraphicsWindow, where you can get the EventQueue from it
seems. We
use a GraphicsWindowEmbedded as the GraphicsWindow, so that OSG re-
uses the
context provided by Equalizer instead of creating its own window.
Not sure if
that already provides an EventQueue, maybe you need to derive from
it.
With mViewer->getEventQueue()->keyPress('a'); you can directly
"simulate" a keypress of char 'a'.
But in the config class, where eqOSG currently handles the Equalizer
events, we don't have access to the viewer instance, which is a
member of the pipe class. What would be the smartest design-approach
to pass the events to the viewer?
Currently I just save the pressed key in the FrameData as a char
member and raise the event in the Pipe::updateSceneGraph() method,
which does more or less what it should, but is still a big hack.
Any creative ideas out there?
There are different use cases, I guess:
1) Some events you directly want to pass to the view on the client in
(OS)Window::processEvent, e.g., window resize.
2) Events modifying the SG you want to handle in Config::processEvent,
and then distribute the changes to all render clients using FrameData,
either as distributed objects or as a list of commands to execute
3) Events modifying the Camera are already handled in the second way,
iirc.
I don't know how use case 2) is implemented in OSG.
Keep in mind that the application doesn't necessarily have a viewer,
i.e., when there is no appNode.
I hope SG modifications are not done in the viewer's event queue.
Ideally the data flow is:
recv event -> create command -> enqueue command in FrameData
appNode: process enqueued commands, start frame
render client: process enqueued commands
For events modifying the viewer state (e.g. stats mode) you probably
want to put the viewer state in the frame data (or in a subclass of
eq::View, if you want to keep it view-specific). Ideally the code
changing the viewer state doesn't need an osgViewer, i.e., you do all
the work in Config::handleEvent, and then copy the viewer state from
framedata into each osgViewer at the beginning of the frame.
HTH,
Stefan.
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
