Hi Robert I shall prepare a copy against trunk tomorrow.
Regarding the inverted matrices - my gut feeling is that these files are actually wrong, or at least so unusual as to be effectively wrong regardless of what any written standard might say. However, I have my doubts getting the manufacturer to modify their files since they are already delivered all over the place... However with a little extra thought I see that we could dispense with the 3rd part of the fix anyway. We're in the lucky position on knowing in advance that the 3DS files we are loading come from this particular source, and so we know that their matrices expect to be applied "as is" and not be inverted. Since in the first bugfix I label the (inverted) MatrixTransform it would be possible for the user's code to load the file then traverse the scenegraph to the correct MatrixTransform and invert it back to its original value. That would result in a cleaner patch for OSG and still allow user's to deal with these particular files. best Mike On 29 May 2012 14:09, Robert Osfield <[email protected]> wrote: > Hi Mike, > > Could you apply the changes to svn/trunk please, this will avoid me > making any inappropriate merges. > > W.r.t the inversion of matrices, this sounds wrong to me, not your > code but the fact that 3ds files might have differing conventions for > their internal matrices, it rather sounds like a bug in the export > tool that created the problem 3ds files. Do you have any idea what > tool created the problem 3ds files? Have you tried loading these > problem 3ds files into any other tools that support 3ds import? > > Robert. > > On 29 May 2012 12:03, Mike Connell <[email protected]> wrote: > > Hi Robert (and everyone else!) > > > > Here's a small change for the 3DS plugin. The attached file is against > 3.0.0 > > but should merge against 3.0-head directly. If the changes look OK to you > > I'll submit a similar patch against trunk (I don't think this patch will > > merge against trunk as there has been further development of the 3DS > plugin > > there). > > > > The changes are: > > > > 1. Bugfix: The 3DS loader defaults to not baking matrix transforms into > the > > mesh data but instead creates MatrixTransform nodes. However we missed > the > > case where the mesh itself has a matrix ("on the side") and were baking > that > > transform down into the Geometry regardless. Fixing this is the the major > > part of the patch > > > > 2. Trivial bugfix: The loader contains two ways to traverse the 3DS > > structure, by mesh or by node. The variable that controls the choice had > the > > wrong name - "traverse_nodes" was true when we traversed by mesh and > false > > when we traversed by nodes > > > > 3. New feature. In the current 3DS loader any transform matrices are > > inverted before being applied. We are seeing a number of 3DS files where > the > > mesh is in a local coordinate system and contains a transform to push > that > > mesh out to some "real world" coordinates. This transform is expected to > be > > applied "as is" and obviously this doesn't work well when the matrix is > > inverted by the loader. I don't know enough about the 3DS format to say > if > > either the code or the files are simply "wrong", or if this is just the > > result of so many programs creating 3DS files. Either way the patch > includes > > a new Options string "3DSDoNotInvertMatrices" that skips the matrix > > inversion. Without this string the 3DS loader inverts matrices as usual. > > > > best wishes > > > > Mike > > > > _______________________________________________ > > 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
