Thanks for your input. Having transpose matrices is definitely not my
problem (I've checked how the matrices are stored and tried both ways
anyway), but it could be a pitfall for some people.
Reading through your posts I have picked up on something though; I
didn't realise quite what the multiplication order was: I knew vectors v
were pre-multiplied as M(v) = M*v:
[ ] ( )
[ M ] * ( v )
[ ] ( )
(yes it's a 4x4 matrix; I'm just showing the ordering and column vector)
What I then assumed was that matrix adjustments by a matrix T were also
pre-multiplied (when I say pre/post-multiplication, I mean the
adjustment matrix is pre/post): TM --- but they're not, they're
post-multiplied: MT (where M is the original matrix and T is the
adjustment - rotation, translation, whatever). This does actually make
sense now I think of it..
So the total multiplication order, where F is the frustum matrix, M1 the
first matrix affecting v, M2 the second, is like this:
F * M2 * M1 * v
For both OpenGL and OSG. Right? Well maybe not. I tried just
reimplementing it like this, and then creating the frustum matrix as the
transposed version of what Matrix_implementation.cpp creates (so that
the results should be the same as direct OpenGL calls) and both times
ended up with a rather messy screen as a result.
First, could someone please tell me how to REALLY disable automatic
computation of the near and far clipping planes (because at the moment
everything's clipped to a narrow band, strangely, one that isn't
parallel to the screen) ? I've already called:
cam->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR)
on all my osg::CameraNode s and:
setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR)
on my sceneView.
I'm guessing I'm trying to set the matrices in a different way to what
OSG normally does. This might not work well though.
Diggory
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
