Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Robert,
thank you for have interest for my previous post, I'll try the latest svn
version as soon as possible.
2009/5/21 Robert Osfield robert.osfi...@gmail.com
HI Alexandre,
I've now had a chance to have a look at the reproducing the problems
using your modified example and data. The problem was due to a
double scaling of the projection matrices due to the unusual
combination of having an active master and slave combination, and
while the usage case in not really what osgViewer was designed for
it's still a bug.
The solution to this bug was applying the inverse of the master's
rescaling to the slave's projection offset. I applied this solution
and tested against your modified osgwindows example and it now behaves
fine, with the two cameras staying in sync. This fix is now checked
into svn/trunk.
Robert.
On Fri, May 15, 2009 at 9:55 AM, Alexandre Amalric
alex.pix...@gmail.com wrote:
Hi osg-users,
I apparently found something strange when adding slave camera to osg
viewer
and resizing window.
I'm using osg SVN version
I made a quick sample code to show community the weird behaviour.
Quick explanation : My goal is to render an object made from 2 cubes
(same
size), one is opaque and the other one is transparent. The first main
camera
render only the opaque part, and the second camera (a slave one) render
the
transparent part. When resizing the window the projection matrix isn't
well
computed for the slave camera.
So the transparent cube isn't the same aspect as the opaque cube.
I think I found the bug in GraphicsContext.cpp file at :
if (slave camera-getReferenceFrame()==osg::Transform::RELATIVE_RF)
{
switch(view-getCamera()-getProjectionResizePolicy())
{
case(osg::Camera::HORIZONTAL):
slave-_projectionOffset
*= osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break;
case(osg::Camera::VERTICAL): slave-_projectionOffset
*=
osg::Matrix::scale(1.0, aspectRatioChange,1.0); break;
default: break;
}
}
I do not understand why we only update the projectionOffset from the
slave
camera and why we don't update the projection matrix itself.
Hope you'll understand my problem ;-)
--
Alexandre AMALRIC Ingénieur RD
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Alexandre AMALRIC Ingénieur RD
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
HI Alexandre,
I've now had a chance to have a look at the reproducing the problems
using your modified example and data. The problem was due to a
double scaling of the projection matrices due to the unusual
combination of having an active master and slave combination, and
while the usage case in not really what osgViewer was designed for
it's still a bug.
The solution to this bug was applying the inverse of the master's
rescaling to the slave's projection offset. I applied this solution
and tested against your modified osgwindows example and it now behaves
fine, with the two cameras staying in sync. This fix is now checked
into svn/trunk.
Robert.
On Fri, May 15, 2009 at 9:55 AM, Alexandre Amalric
alex.pix...@gmail.com wrote:
Hi osg-users,
I apparently found something strange when adding slave camera to osg viewer
and resizing window.
I'm using osg SVN version
I made a quick sample code to show community the weird behaviour.
Quick explanation : My goal is to render an object made from 2 cubes (same
size), one is opaque and the other one is transparent. The first main camera
render only the opaque part, and the second camera (a slave one) render the
transparent part. When resizing the window the projection matrix isn't well
computed for the slave camera.
So the transparent cube isn't the same aspect as the opaque cube.
I think I found the bug in GraphicsContext.cpp file at :
if (slave camera-getReferenceFrame()==osg::Transform::RELATIVE_RF)
{
switch(view-getCamera()-getProjectionResizePolicy())
{
case(osg::Camera::HORIZONTAL): slave-_projectionOffset
*= osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break;
case(osg::Camera::VERTICAL): slave-_projectionOffset *=
osg::Matrix::scale(1.0, aspectRatioChange,1.0); break;
default: break;
}
}
I do not understand why we only update the projectionOffset from the slave
camera and why we don't update the projection matrix itself.
Hope you'll understand my problem ;-)
--
Alexandre AMALRIC Ingénieur RD
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Jean Sébastien, apparently my bug is due to bad view matrix, my shader need camera view matrix to compute it's effect. What you're proposing is to copy slave camera view matrix into master (default) camera matrix each frame, am I right ? Isn't it another way yo avoid this copy ? isn't it a little expensive ? 2009/5/15 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hello Alexandre, Well apparently I did achieve to set up my application with 2 slave camera, but there is one last problem, I'm using a shader for my sky sphere wich isn't working when using 2 slave cameras, has anyone already had trouble with shaders and slave camera ? Do you mean that (for example) lighting calculations give the wrong results? IIRC, if you need the projection/view matrix then you can't use the built-in uniform from OpenGL, because that will be your slave camera's projection/view matrix. You need the master view's matrices, which means you'll have to copy the master camera's matrices into uniforms each frame. If that wasn't the problem, you'll have to be more clear. What do you mean by a shader which isn't working? How is it not working? Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hello Alexandre, What you're proposing is to copy slave camera view matrix into master (default) camera matrix each frame, am I right ? Isn't it another way yo avoid this copy ? isn't it a little expensive ? No, I'm proposing to copy the slave camera's view matrix into an osg::Uniform each frame so that you can use it from the shader for your lighting computations. It's not that expensive, no, and it's required so you can't really do without... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Alexandre, On Fri, May 15, 2009 at 9:55 AM, Alexandre Amalric alex.pix...@gmail.com wrote: I do not understand why we only update the projectionOffset from the slave camera and why we don't update the projection matrix itself. The slave uses a relative reference frame the camera's projection matrix is update on each new frame by multiplying the master's camer's projection matrix by the projection offset matrix of the slave. So there isn't any point modifying the slave's projection matrix as it'll be overritten anyway. In your example I wonder if the problem is down to your have two camera's, and master camera that is assigned to the graphics window so gets resized, and a slave camera that gets assigned to the also gets it's offset resized, putting these two resizes together you'll end up with a double resize. Could you changing you example so that the you have the viewer's master camera (not assigned to the graphics context) , then two slave cameras to see if it works fine. In terms of catching this particular usage model in the resize code... it's a bit awkward, if the master camera to a slave has been resized and the slave has a relative reference frame then it shouldn't be resized. This only works if the master camera shares the same graphics context, if it doesn't then you'll be a bit stuck as you'd have to apply the inverse of the master's projection matrix's resizing to the slaves. Perhaps this could be done by the resize code detecting a master/slave set up where double resizes are present, and then have inverse of the resizes to the master pass down to the slave. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Robert,
thank you for answering me but i'm confused I don't really understand what
you want me to do on my example ?
In fact the problem is that resizedImplementation function is called 1 time,
then there is a loop on _cameras vector (filled with 2 cameras in my
example, the main and the slave).
During this loop, the projection is updated for the main camera then the
offset projection is updated for the slave camera.
After resizedImplementation function is finished, there is a call to void
View::updateSlave(unsigned int i) function wich update my slave camera
projection by multiplying the main camera projection matrix (wich is already
updated) by the offset projection computed earlier. So the projection matrix
from the slave camera is different from the main camera projection matrix.
I hope I'm clear, but seems to me that it's very important to correct that.
If it's help I achieve to avoid the weird behaviour by replacing in
GraphicsContext.cpp :
if (slave camera-getReferenceFrame()==osg::Transform::RELATIVE_RF)
{
switch(view-getCamera()-getProjectionResizePolicy())
{
case(osg::Camera::HORIZONTAL): slave-_projectionOffset
*= osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break;
case(osg::Camera::VERTICAL): slave-_projectionOffset *=
osg::Matrix::scale(1.0, aspectRatioChange,1.0); break;
default: break;
}
}
*by *
if (slave camera-getReferenceFrame()==osg::Transform::RELATIVE_RF)
{
switch(view-getCamera()-getProjectionResizePolicy())
{
case(osg::Camera::HORIZONTAL):
slave-_camera-getProjectionMatrix() *=
osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break;
case(osg::Camera::VERTICAL):
slave-_camera-getProjectionMatrix() *= osg::Matrix::scale(1.0,
aspectRatioChange,1.0); break;
default: break;
}
}
2009/5/15 Robert Osfield robert.osfi...@gmail.com
Hi Alexandre,
On Fri, May 15, 2009 at 9:55 AM, Alexandre Amalric
alex.pix...@gmail.com wrote:
I do not understand why we only update the projectionOffset from the
slave
camera and why we don't update the projection matrix itself.
The slave uses a relative reference frame the camera's projection
matrix is update on each new frame by multiplying the master's camer's
projection matrix by the projection offset matrix of the slave. So
there isn't any point modifying the slave's projection matrix as it'll
be overritten anyway.
In your example I wonder if the problem is down to your have two
camera's, and master camera that is assigned to the graphics window so
gets resized, and a slave camera that gets assigned to the also gets
it's offset resized, putting these two resizes together you'll end up
with a double resize.
Could you changing you example so that the you have the viewer's
master camera (not assigned to the graphics context) , then two slave
cameras to see if it works fine.
In terms of catching this particular usage model in the resize code...
it's a bit awkward, if the master camera to a slave has been resized
and the slave has a relative reference frame then it shouldn't be
resized. This only works if the master camera shares the same
graphics context, if it doesn't then you'll be a bit stuck as you'd
have to apply the inverse of the master's projection matrix's resizing
to the slaves.
Perhaps this could be done by the resize code detecting a master/slave
set up where double resizes are present, and then have inverse of the
resizes to the master pass down to the slave.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Alexandre AMALRIC Ingénieur RD
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
HI Alexandre, On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric alex.pix...@gmail.com wrote: Hi Robert, thank you for answering me but i'm confused I don't really understand what you want me to do on my example ? Make it work like the original osgwindows example - use two slave cameras rather than one master and one slave. I have lots of other work to do, and I'm really not well so can't take on extra work, please try out my suggestions. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
When using 2 slave cameras instead of 1 main calera and 1 slave camera the resizing works perfectly. I was thinking that the viewer had to have 1 main camera and n slave camera, I was mistaken. I have one last question, when we call getCameraWithFocus on a viewer set up with 2 slaves camera and no main camera, wich one is returned ? Thank you for your support and I wish you a good recovery. 2009/5/15 Robert Osfield robert.osfi...@gmail.com HI Alexandre, On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric alex.pix...@gmail.com wrote: Hi Robert, thank you for answering me but i'm confused I don't really understand what you want me to do on my example ? Make it work like the original osgwindows example - use two slave cameras rather than one master and one slave. I have lots of other work to do, and I'm really not well so can't take on extra work, please try out my suggestions. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi robert, something isn't right with the last thing I said, when creating a new osgViewer::View a main camera is created by default, so it's not possible to have 2 slave cameras only and no main camera, am I right ? My goal is to have only 2 camera not matter if they are both slaves or main and slave but they have to get the same projection matrix when resizing. With you recommandation there is in fact 3 cameras (2 slave and 1 main default created). What is the problem with changing the part of code I previously spoke about ?? 2009/5/15 Alexandre Amalric alex.pix...@gmail.com When using 2 slave cameras instead of 1 main calera and 1 slave camera the resizing works perfectly. I was thinking that the viewer had to have 1 main camera and n slave camera, I was mistaken. I have one last question, when we call getCameraWithFocus on a viewer set up with 2 slaves camera and no main camera, wich one is returned ? Thank you for your support and I wish you a good recovery. 2009/5/15 Robert Osfield robert.osfi...@gmail.com HI Alexandre, On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric alex.pix...@gmail.com wrote: Hi Robert, thank you for answering me but i'm confused I don't really understand what you want me to do on my example ? Make it work like the original osgwindows example - use two slave cameras rather than one master and one slave. I have lots of other work to do, and I'm really not well so can't take on extra work, please try out my suggestions. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Alexandre, I'm afraid others will have to pick up this thread to answer your questions. Robert. On Fri, May 15, 2009 at 1:51 PM, Alexandre Amalric alex.pix...@gmail.com wrote: Hi robert, something isn't right with the last thing I said, when creating a new osgViewer::View a main camera is created by default, so it's not possible to have 2 slave cameras only and no main camera, am I right ? My goal is to have only 2 camera not matter if they are both slaves or main and slave but they have to get the same projection matrix when resizing. With you recommandation there is in fact 3 cameras (2 slave and 1 main default created). What is the problem with changing the part of code I previously spoke about ?? 2009/5/15 Alexandre Amalric alex.pix...@gmail.com When using 2 slave cameras instead of 1 main calera and 1 slave camera the resizing works perfectly. I was thinking that the viewer had to have 1 main camera and n slave camera, I was mistaken. I have one last question, when we call getCameraWithFocus on a viewer set up with 2 slaves camera and no main camera, wich one is returned ? Thank you for your support and I wish you a good recovery. 2009/5/15 Robert Osfield robert.osfi...@gmail.com HI Alexandre, On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric alex.pix...@gmail.com wrote: Hi Robert, thank you for answering me but i'm confused I don't really understand what you want me to do on my example ? Make it work like the original osgwindows example - use two slave cameras rather than one master and one slave. I have lots of other work to do, and I'm really not well so can't take on extra work, please try out my suggestions. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Alexandre, something isn't right with the last thing I said, when creating a new osgViewer::View a main camera is created by default, so it's not possible to have 2 slave cameras only and no main camera, am I right ? Of course, an osgViewer::View will always have a main camera. This is the camera that is used for user interaction, etc. But it does not render anything, only the two slaves have GraphicsContexts attached. Check it out, try view-getCamera()-getGraphicsContext(), you will get 0, but if you try it on both slaves you will get a valid GraphicsContext (it could be the same one). So your goal of having only 2 cameras rendering will be met by this setup. The slave cameras render using view and projection matrix offsets from the master camera, and user interaction (say using a camera manipulator) moves the main camera's view matrix and thus affects the slaves indirectly. Hope this clears things up, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi jean-sébastien, Your explanation is very clear. My problem is that when I configure my application like that (2 slaves cameras) I have a lot of weird behaviour (some of my models aren't displayed, interraction with mouse and keyboard are odd), so I found a much simple solution wich is to set my own resize callback to my graphic context. In my resize implementation I directly update the projection matrix from the slave camera and I don't update the _projectionOffset wich for me is useless. I still think that future osg version should correct the default resizeimplementation because this behaviour seems very strange to me, maybe am I the only one to think so ;-) 2009/5/15 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hi Alexandre, something isn't right with the last thing I said, when creating a new osgViewer::View a main camera is created by default, so it's not possible to have 2 slave cameras only and no main camera, am I right ? Of course, an osgViewer::View will always have a main camera. This is the camera that is used for user interaction, etc. But it does not render anything, only the two slaves have GraphicsContexts attached. Check it out, try view-getCamera()-getGraphicsContext(), you will get 0, but if you try it on both slaves you will get a valid GraphicsContext (it could be the same one). So your goal of having only 2 cameras rendering will be met by this setup. The slave cameras render using view and projection matrix offsets from the master camera, and user interaction (say using a camera manipulator) moves the main camera's view matrix and thus affects the slaves indirectly. Hope this clears things up, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Alexandre, In my resize implementation I directly update the projection matrix from the slave camera and I don't update the _projectionOffset wich for me is useless. Why don't you update the projection matrix of the master camera? If both slave cameras render to the same GraphicsContext (i.e. are in the same window) then it's the right thing to do. You shouldn't touch the slave cameras' projection matrices, only the master camera's projection matrix and the slave cameras' projection offsets. I still think that future osg version should correct the default resizeimplementation because this behaviour seems very strange to me, maybe am I the only one to think so ;-) Well if you mean that it doesn't do the right thing when you have one master camera and one slave camera, both with graphics contexts, then you're right, but that's expected because it's not a valid use case. You should use a master camera with no graphics context, and two slave cameras with graphics contexts (perhaps the same one). See the code for osgViewer::View::setUpViewOnAllScreens() for an example of this. Perhaps a test could be added to catch that kind of utilization and warn the user that their view's camera setup is invalid. Go back to my previous message, really it makes sense. You have the master camera which in this case is only there to represent the viewer's position. So that's what the CameraManipulator acts upon, but it has no GraphicsContext so it doesn't render anything by itself. And then you have two slave cameras which have viewpoints and projections offset from the master camera, and which do the actual rendering, hence they have GraphicsContexts. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Well apparently I did achieve to set up my application with 2 slave camera, but there is one last problem, I'm using a shader for my sky sphere wich isn't working when using 2 slave cameras, has anyone already had trouble with shaders and slave camera ? 2009/5/15 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hi Alexandre, In my resize implementation I directly update the projection matrix from the slave camera and I don't update the _projectionOffset wich for me is useless. Why don't you update the projection matrix of the master camera? If both slave cameras render to the same GraphicsContext (i.e. are in the same window) then it's the right thing to do. You shouldn't touch the slave cameras' projection matrices, only the master camera's projection matrix and the slave cameras' projection offsets. I still think that future osg version should correct the default resizeimplementation because this behaviour seems very strange to me, maybe am I the only one to think so ;-) Well if you mean that it doesn't do the right thing when you have one master camera and one slave camera, both with graphics contexts, then you're right, but that's expected because it's not a valid use case. You should use a master camera with no graphics context, and two slave cameras with graphics contexts (perhaps the same one). See the code for osgViewer::View::setUpViewOnAllScreens() for an example of this. Perhaps a test could be added to catch that kind of utilization and warn the user that their view's camera setup is invalid. Go back to my previous message, really it makes sense. You have the master camera which in this case is only there to represent the viewer's position. So that's what the CameraManipulator acts upon, but it has no GraphicsContext so it doesn't render anything by itself. And then you have two slave cameras which have viewpoints and projections offset from the master camera, and which do the actual rendering, hence they have GraphicsContexts. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hello Alexandre, Well apparently I did achieve to set up my application with 2 slave camera, but there is one last problem, I'm using a shader for my sky sphere wich isn't working when using 2 slave cameras, has anyone already had trouble with shaders and slave camera ? Do you mean that (for example) lighting calculations give the wrong results? IIRC, if you need the projection/view matrix then you can't use the built-in uniform from OpenGL, because that will be your slave camera's projection/view matrix. You need the master view's matrices, which means you'll have to copy the master camera's matrices into uniforms each frame. If that wasn't the problem, you'll have to be more clear. What do you mean by a shader which isn't working? How is it not working? Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
