On Mon, 2012-08-27 at 15:12 -0400, Judson Weissert wrote: > 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,
A Drawable can have a special ComputeBoundsCallback() (something like that, I'm on my phone right now and can't look it up), so you could use that as well... > Judson > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
