Hi Wojtek, I was wondering if the change may introduces errors in end user apps like your suggest. I see a couple of cases:
A) Modern VPB databases are actually created by default using osgTerrain::TerrainTile, and these compute the coordinates on the fly, so will honour which ever version of local coordinate frame that EllipsoidModel suggests at runtime, so there won't be an inconsistency if developers rely upon this same EllipsoidModel. B) Cases where a polygonal VPB database is generated prior to this change, and then at runtime the developer using the new EllipsoidModel and assumes that the local coodindate system for the tile is the same as the one that that on the pre-generated tiles. C) Developer has pre generated data in a local coordinate frame set be the previous rev of EllipsoidModel and is mixing this will data computed at runtime using EllipsoidModel (such as new VPB database that using osgTerrain::TerrainTile. Case A is in the clear, Case B and C and basically the same thing - mixing of two different compute local coordinate frames, both these cases make the assumption that the generated data and the runtime data will fit. Updating the pre computed data or adapting at runtime will be required. If users need to do the adapting at runtime then perhaps providing the old implementations of computeLocalToWorld and computing the up vector would be appropriate. Robert. On Thu, Aug 20, 2009 at 2:45 PM, Wojciech Lewandowski<[email protected]> wrote: > Hi Robert and Ronald, > > (please don't stop reading after 1 paragraph) > > We once had a problem with our proprietary tool when we placed and oriented > few models to lie on the surface of the osgDEM world. This tool was using > the same local coordinate frame math as the new one that Ronald submitted. > But in target OSG application we computed model matrices using > EllipsoidModel::computeLocalToWorld based on model center geographical > position and orientation. For large objects like runways we observed that > one end of the airport was buried in the ground while other end was flying > above the ground. That was because local surface orientation was bit > different in OSG. This situation may be reversed now but problems for some > users may be similar if they had "preoriented" their models to match earth > surface using former OSG coordinate frame. They may need to adjust their > models to match new frame if the code thay use rely on localCoordinateFrame > computed from latitude and longitude. > > I mention above case to only illustrate what possible issues may appear. Its > not may intent to block the submission. In fact I am glad you're going to > merge it. I played bit of a devils advocate in discussion with Ronald. After > that I had the feeling that I voiced to strong objections and the idea was > abandoned. But I am really glad its not and I think this is a move in good > direction. > > Cheers, > Wojtek Lewandowski > > PS. In our tool we computed our local coordinate frame using formula below. > Looks like Ronald results should be the same: > > double X,Y,Z; > ellipsoid->convertLatLongHeightToXYZ( latitude, longitude, altitude, X, Y, Z > ); > > localToWorldTransform = > osg::Matrix::rotate( osg::PI_2 - latitude, 1, 0, 0 ) * > osg::Matrix::rotate( osg::PI_2 + longitude, 0, 0, 1 ) * > osg::Matrix::translate( X,Y,Z ); > > > ----- Original Message ----- From: "Robert Osfield" > <[email protected]> > To: "OpenSceneGraph Submissions" <[email protected]> > Sent: Thursday, August 20, 2009 2:18 PM > Subject: Re: [osg-submissions] EllipsoidModel::computeLocalUpVector > > >> Hi Ronald, >> >> I've done a review of your changes, merged and tested them and all >> look sound. I've also adapted your suggested changes to >> computeLocalToWorld*() methods so that compute the local reference >> frame is done in a separate method and then shared between the two >> computeLocalToWorld implmentations. This should reduce the potential >> for bugs to slip into the what would have been duplicated code paths. >> The code looks like: >> >> >> inline void >> EllipsoidModel::computeLocalToWorldTransformFromLatLongHeight(double >> latitude, double longitude, double height, osg::Matrixd& localToWorld) >> const >> { >> double X, Y, Z; >> convertLatLongHeightToXYZ(latitude,longitude,height,X,Y,Z); >> >> localToWorld.makeTranslate(X,Y,Z); >> computeCoordinateFrame(latitude, longitude, localToWorld); >> } >> >> inline void EllipsoidModel::computeLocalToWorldTransformFromXYZ(double >> X, double Y, double Z, osg::Matrixd& localToWorld) const >> { >> double latitude, longitude, height; >> convertXYZToLatLongHeight(X,Y,Z,latitude,longitude,height); >> >> localToWorld.makeTranslate(X,Y,Z); >> computeCoordinateFrame(latitude, longitude, localToWorld); >> } >> >> inline void EllipsoidModel::computeCoordinateFrame(double latitude, >> double longitude, osg::Matrixd& localToWorld) const >> { >> // Compute up vector >> osg::Vec3d up ( cos(longitude)*cos(latitude), >> sin(longitude)*cos(latitude), sin(latitude)); >> >> // Compute east vector >> osg::Vec3d east (-sin(longitude), cos(longitude), 0); >> >> // Compute north vector = outer product up x east >> osg::Vec3d north = up ^ east; >> >> // set matrix >> localToWorld(0,0) = east[0]; >> localToWorld(0,1) = east[1]; >> localToWorld(0,2) = east[2]; >> >> localToWorld(1,0) = north[0]; >> localToWorld(1,1) = north[1]; >> localToWorld(1,2) = north[2]; >> >> localToWorld(2,0) = up[0]; >> localToWorld(2,1) = up[1]; >> localToWorld(2,2) = up[2]; >> } >> >> I've done my own preliminary testing that suggests it's OK, but I'd >> appreciate a quick review as a sanity check before checking in. >> Complete modified file attached. >> >> Cheers, >> Robert. >> > > > >> _______________________________________________ >> 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
