Guys, I just want to chime in here by saying that I have implemented something like this for some proprietary code I wrote. In my case, I am using Qt's signal/slot mechanism to perform the mapping between an input device (mouse, joystick[s], spacenavigator, etc) and an effect (camera manipulation, enable/disable featureX, ...). I created what I called a slotManager that is persistent and its sole purpose is to direct input devices to some desired action. Since it uses Qt's signal/slot mechanism, it doesn't require knowledge of the implementation particulars, just needs to be smart enough to fire off execution of the event. It works similar to an ORB, where you can publish and subscribe to events of your choosing. I have a front-end GUI that allows for device mapping and configuration for axes and buttons on a per-device basis.
It works for me, but it can be seen as overkill for the majority of users. I suspect for the general user, the default classes would be close enough that only minor tweaking would be necessary to achieve the desired result. Coming up with something that does the same thing, but doesn't require Qt is also a good amount of work to make general purpose. I am just about to look into the latest (>2.9.7) changes to camera manipulators to see if a thin Qt layer on top of the new classes would still satisfy my purposes. If so, then I might push some code out to the OSG community to utilize. So no direct help for you right away, but maybe something in the not-so-distant future. Regards, Chuck Seberino On Oct 8, 2010, at 12:58 PM, Jean-Sébastien Guay wrote: > Hi Matt, > >> Your view of how the system would work is probably very similar to what I >> had in mind. > > Thanks for the explanation, and yes it's very similar to what I was thinking > too. > > How would you map the input (gotten by the GUIEventHandler) to calls to the > manipulator's functions in a general way? Because you wouldn't want one > handler per manipulator (that would be almost the same as what we have now, > just more code and more spread out), or even to have if (flightmanip) > flightmanip->pitch(val) else if (trackballmanip) trackballmanip->rotateY(val) > else ... in the event handler (even worse than what we have now). > > I was talking about connections before, that kind of thing is a bit hard to > design so that it's minimally intrusive and as general as possible at the > same time... The interfaces I've seen that attempted to implement connections > in a very general way had an extremely verbose API, and then you would get > google-eyed when you'd look at the setup code and might miss typos and small > bugs... > > I'm just asking by curiosity... You could just code up your solution and send > it, and stop wasting time replying to my questions :-) . I have no authority > over what gets committed in OSG. I just wanted to know what you have in mind. > >> Also, J-S, I didn't really understand the point you were trying to make in >> your final paragraph: >> >>> I would suggest that axes be mappable to either an analog axis (say >>> mouse up/down or joystick y axis) or a pair of buttons (one for >>> incrementing and one for decrementing the value). > > Well, sometimes you run out of axes but have buttons to spare, and you could > map two buttons to do (digitally) what an analog axis would normally do. I > know I could just subclass and do what I want, but I think it would be a cool > feature. > > For example, you said pitch(force) would accept magnitudes [-1,1]. Then you'd > map an axis on an analog stick on your joystick to send, say, pitch(X) where > X would map [-1,1] to the [down,up] range. But say you had two buttons and > wanted to do the same thing, you could have button A send pitch(0.5) and > button B send pitch(-0.5) for example. > > I'm just saying that if you can connect some value to an analog input that > takes a range, you should also be able to connect that value to two digital > inputs that go up and down as well. That's classic in games, where say the > left/right steering of a car can either map to a joystick axis, or to the > left/right arrow keys on your keyboard. > > Geez, a long explanation for what's basically a detail that could have been > added later... That's me. Sorry about that. > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
