Hi Jan, It's simply not possible to set a PositionAttiudeTransform up using a setMatrix() as there are simply too my unknowns to set, PositionAtttitudeTransform is also not alone as there are other Transform subclasses like osg::AutoTransform that won't fit the simple one sit fits all approach your desire.
Perhaps another approach would be to have a vertex Transform::mult(Matrix&) method that allows one to apply a matrix to update it's position, but some transform classes like AutoTransform would find this problematic to implement as the value would be likely be discarded on the next frame. Robert. On Sun, Oct 24, 2010 at 6:10 PM, Jan Ciger <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Robert, > >> Hi Jan, >> >> This is rather tangential to this thread - and should be asked on >> another to make it easy to tracke. > > Sorry for the thread hijack I wanted only quickie answer, but it seems > the issue is more complex. > > >> But I'll answer quickly here as >> it's a one line. MatrixTransform and PositionAttiudeTransform are >> both subclasses from osg::Transform, and osg::Transform provides >> generic methods for getting the modelview matrix after the transform >> is applied. See the Transform::computeLocalToWorldMatrix(..) method, >> this is what you should be using in your codes. > > This is not really the use case I have encountered. My problem usually > rears its ugly head when I am trying to animate or move objects around > in the scene. > > A typical configuration I have is a hierarchy where at the root is > either MatrixTransform or PositionAttitudeTransform which have as > children my geometry (or whatever needing positioning). I keep a map to > be able to quickly look up the transform nodes by name, because the > commands to move the geometry around are coming from outside, over > network. Now the problem arrives when I am to move an object - I have to > test if the transform is a MatrixTransform and use setMatrix method or > if it is a PositionAttitudeTransform, then I have to use > setPosition/setAttitude. Essentially every piece of code needing to > manipulate the node somehow needs this type of check. Ugly. > > If PositionAttitudeTransform was a subclass of MatrixTransform, I could > always use setMatrix() in the generic code and the > setPosition/setAttitude would be convenience methods. Of course, > setMatrix could do also scaling and shearing, so perhaps an overriden > version with a sanity check in the PositionAttitudeTransform (PAT) would > be in order, but that is a detail. > > Right now I have worked this issue around by standardizing on only > MatrixTransforms and always building the positioning matrices up myself. > It feels like reinventing the wheel, because that is what the PAT seems > to be made for. > > Regards, > > Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org/ > > iD8DBQFMxGiIn11XseNj94gRAg7nAJ45g1tbE1jsi3AcF5ybW4TXuY3HEgCg1QjS > WKtA2zlvzqKQYmy6wXTpj3A= > =7ym3 > -----END PGP SIGNATURE----- > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
