Hi John, I've merged your latest changes and am currently testing them. One thing I've tweaked is to add a DEFAULT_SETTTINGS enum value to StandardManipulator and then use this in the subclasses where appropriate, and have set the DEFAULT_SETTINGS to UPDATE_MODEL_SIZE | COMPUTE_HOME_USING_BBOX | PROCESS_MOUSE_WHEEL.
I didn't include the SET_CENTER_ON_WHEEL_UP in DEFAULT_SETTINGS as while I understand your motivation behind this I don't feel that it's intuitive use of the mouse wheel - zooming in/out or altering the pitch yes, moving to a new location does seem appropriate. Perhaps a double click or a key press would be more intuitive for people. There seems to be two regressions. One is FlightManipulator now stops moving when you press the middle or right mouse buttons rather than just continuing to move the eye point as it did originally. Aircraft don't just stop mid air when you change the throttle setting. Curiously the DriveManipulator is working just fine and it behaves in the same way w.r.t speeding up/slowing down. Another regression (w.r.t svn/trunk at least) is that the trackball had been updated so that it's throw speed didn't change with the frame rate. I'm going to revert to svn/trunk to just double check this. Robert. On Mon, May 24, 2010 at 3:53 PM, PCJohn <[email protected]> wrote: > Hi Robert, > > I made one more fix in StandardManipulator (compile problem on MSVC) > and put minor copyright as this was done for mentioned institutions. Let me > know if there will be a need for adjustments. > > Concerning osgGA::SphericalManipulator, I will take a look on it. > Unfortunately, I have some duties tomorrow, so probably on Wednesday. I > expect that spherical manipulator can be fused with OrbitManipulator, or it > can be made a descendant class. My goal was to generalize and reuse as much > code as possible in FirstPersonManipulator and OrbitManipulator that > represents two most used types of manipulators. Descendant classes often > customize few things only, reusing much of functionality of the parent > class. > > About the cow.osg, Trackball/Orbit Manipulator and SCROLL_UP: I implemented > view centering on SCROLL_UP event. It casts a ray to the scene and closest > intersection point is used as a new center. If there is no intersection > (mouse is not pointing at any geometry), it makes just zoom/move forward. We > are using such functionality in Cadwork for four years in our software. It > is very useful for CAD, particularly large landscape/city models to quickly > zoom to particular place/building and examine it. Or moving in CAD-designed > simple buildings/interiours. This is the most efficient in combination with > FirstPersonManipulator. FirstPerson for look around and OrbitManip with > SCROLL_UP centering to quickly come to the new point of interest inside > interiour (table, picture on wall, ...). Feel free to provide comments, > especially if something does not seem natural for humans in your opinion. > Ideas are always interesting. I will see my time possibilities whether I > will be able to do something for them. > > If you notice some behavior that is not according what I wrote above (bug), > let me know. > > I made also a kind of animation doing the centering. It can be still > improved. Probably the mouse warp should be done in more steps, as it does > not give a perfect impression jet. Other issue is on huge models and very > low FPS: first animation frame is at the original position as I do not know > approximate time of frame. Thus, it seems like nothing is happening because > the first frame rendering (at original position) takes time. If I would know > approximate frame time, I would be able to adjust animation of the first > frame. Is there such information (approximate frame time / time of the last > rendered frame) available in OSG? > > As I am switching to OSG-trunk now, I noticed, there is SCROLLing handled as > well, at least in Trackball manipulator. I expect, the behavior is not too > much different (except the centering), although adjustments can be made if > needed. > > There is also an option to disable animation and centering. > > I was also in doubts about merging StandardManipulator to MatrixManipulator, > or to use a name different to StandardManipulator. Feel free to provide > comments/suggestions. > > I am attaching osgviewer.cpp with added Orbit and FirstPerson Manipulators. > I made Orbit the first one (Trackball is second) because fixed vertical axis > is more natural for humans, at least compared to rotating freedom of > Trackball that somehow puzzles normal humans that are not programmers ;-). > At least that is our experience at Cadwork. > > Feel free to provide further comments. I am going to make some manipulator > coding soon (SphericalManip.). Then, I will be back. > John > > > Robert Osfield wrote: > > Hi John, > > I'm currently reviewing your changes, so they look to be a significant > improvement for osgGA ;-) > > One question these changes raise is what to do about the > osgGA::SphericalManipulator that made it into the 2.9.x dev series and > svn/trunk since the 2.8.x release. It looks to me that this > manipulator is now redundant as the TrackballManipulator may well be > able to do what it's set up to do. Thoughts? > > Just experimenting with the trackball manipulator usage when looking > at cow.osg using osgviewer I get an odd re-centering of the scene when > using the mouse wheel. This behavior doesn't happen all the time. > I've just to come up with what's actually happening just by > interacting with it, but it doesn't seem consistent so I'm a bit > confused. It looks to be related to the changes you've made, but at > this stage I don't where or why. And ideas of this? > > Cheers, > Robert. > > On Sun, May 16, 2010 at 5:49 PM, PCJohn <[email protected]> wrote: > > > Hi Robert, > > I am submitting improved osgGA camera manipulators. > Changes: > - new mouse wheel zoom/movement/center functionality > - ability to fix vertical axis (important for CAD) > - possibility to specify values as absolute values or relative to model size > - kind of backward compatibility by flags passed to constructor > - and much more > - restructuring classes to use kind of hierarchy and standard way of event > processing (handle methods). This way, there is much more code reusability > and it is more easy to develop new kinds of manipulators. > > Briefly, the new architecture keeps MatrixManipulator as base abstract > class. StandardManipulator is the feature-rich standard manipulator with two > main descendant classes: OrbitManipulator and FirstPersonManipulator. > OrbitManipulator is base class for all trackball style manipulators, based > on center, rotation and distance from center. FirstPersonManipulator is base > for walk or fly style manipulators, using position and rotation for camera > manipulation. > > Unfortunately, I did not had time for all manipulators to make them use the > new architecture. Even the implemented manipulators took me much more time > than I originally want to put in it. > > Submitted View.cpp contains fix for excessive number of CoordinateFrame > messages when no coordinate frame is used. > > You can take a look on the code. I should be able to make minor adjustments > if needed, but I need to switch to other tasks soon as this took me about a > month of coding and debugging. Changes done to OSG 2.8.2. > Thanks, > John > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
