Stefan Eilemann schrieb:
> 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:
In most OSG applications, the OSG Viewer class receives the events. In
eqOSG there is also an osg viewer but without window. The window is
set-up by equalizer. Therefore, my idea is to handle the events still in
Config::handleEvents and then pass some of the events via FrameData to
the pipes osgViewers.
Do we talk of the same? (hmm, is this a known phrase in english? I think
you understand what I mean...)
> 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
>
regards jonas
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
