Hi Luc, On Wed, Jul 3, 2013 at 12:59 PM, Luc Frauciel <luc.frauc...@star-apic.com>wrote:
> Hi jan, > > > >That would be good, I am working on the Rift too, but I am a bit > hampered by weird issues with slave cameras (how to set a projection > matrix on a slave camera correctly?? Mine gets always overridden to > some nonsense). > > When working on slave projection matrix for the Rift, I've done a stupid > mistake leading to some nonsense and took time to understand the issue. > osg has mechanisms to combine projection matrices (it's the case for child > cameras, I assume it is the same for slave cameras), and only expect > 'offset' matrices as child/slave. > So the 'master' projection matrix, which is initialized to some default > frustrum is applied before the others. > With a full projection matrix defined as child/slave, you'll and up with > garbage. > Yes, I have noticed this. I have set the master camera projection to identity and used a full matrix on the slave camera. However, the matrix still gets clobbered after first frame by something. It is not the camera manipulator messing with it - it happens even when no camera manipulators are installed. The resulting matrix has only some scaling and translation set (for whatever reason) and is not a valid projection matrix. Also, the matrix values are changing when I move the camera using the camera manipulator - which is most odd, because that has no reason to touch projection matrices, or?? > By initializing the master matrix to identity, it solved my problem. You > could also only define these slave matrices as an offset from the first one. > Don't know if that's your case, but if that could help... > That is what I did. viewer.getCamera()->setProjectionMatrix(osg::Matrix::identity()) and then set the matrices in full on the slave cameras that are attached to this view. However, it still gets clobbered :( I could, of course, set the slave cameras to use RF_ABSOLUTE, but that loses the advantage of having them as slaves and being able to move cameras using a single view matrix. BTW, this issue doesn't happen if I insert the cameras into the scene directly, not as slaves, so it has to be some mess with the slave update callback doing something strange to the matrices. > > Be also aware that stereo parameters in OSG can put a real mess into your > matrices. I tend to think it's preferable to set them "by hand" when > dealing with asymetric matrices. > For the time being I am not concerned about this. I am trying to get the thing display something semi-correct using symmetrical projections and only horizontal offset in the view matrices first, once that works I will move on to get the proper frusta setup. I am not using the OSG built-in side-by-side stereo code, I am setting up everything by hand. Regards, Jan
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
