On 8/27/2012 2:22 PM, Jeremy Moles wrote: > On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote: >> Hello, >> >> I was hoping someone could help me with a camera manipulator/scaling >> problem that I have been having. >> >> I have a scene graph that contains geometry representing a hydraulic >> fracture. The fracture length is of the order 1000ft, the height is of >> the order 100ft, and the width is of the order .01ft. I am trying to >> appy a width exaggeration factor to the model in order to artificially >> inflate the geometry along the width axis (in my case it is along the >> z-axis). To accomplish this, I call >> osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on >> the PAT node that I use to orient the fracture in the model. This works >> as expected, and the fracture width is exaggerated. However, the camera >> manipulator (osgGA::TrackballManipulator) does not return to the same >> home position. The larger the scale value, the further the home position >> seems to be from the model. Also, the velocity of the camera (model >> distance / screen pixel distance) when manipulated via the mouse >> increases with the scale value. That is, dragging the mouse an inch on >> the screen results in a larger camera manipulation when the scale value >> is increased. >> >> Perhaps I am making some false assumptions regarding how the camera >> manipulators and scaling operations interact? Is the scaling operation >> messing up a bounding box calculation somewhere? I tried computing then >> drawing the bounding box of the root node, but it did not seem to change >> for either case. That is, the exaggerated fracture width does not make >> the overall volume of the scene any larger (as far as I can tell). > I've been working on a custom OrthographicCameraManipulator (and have > done FirstPersonShooter and other kinds of CameraManipulators in the > past) and I've never seen this behave OTHER than how you're describing. > > Scaling the PAT will definitely affect the home position of the > osgGA::StandardManipulator, so you may end up having to do something > like: > > osgGA::CameraManipulator* cm = viewer.getCameraManipulator(); > > cm->setHomePosition(...); > > That should also set autoComputeHomePosition to false, so it'll stick. > > I could, of course, be misunderstanding the question. :)
Thank you. After thinking about what you said, I figured I would revisit my bounding box code. I must have made a mistake the first time around because this time I do get a completely different bounding box for the scene when the scale changes. Therefore, the code that is computing the home position thinks that it needs to view a huge volume, even though most of that volume does not actually contain any drawables. Therefore, I think I need to fix the bounds calculation and then I will still be able to rely on the default ComputeHomePosition algorithm. So far I have just relied on the default bounds() calculations. Thanks, Judson _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
