HI Cory,

Thanks for the cute little example that illustrates the problem.  I've
done another code review and as you point out the second code block
fails because it uses the view's master cameras resize policy rather
than the slave cameras policy.

The code should of course take into account the slave camera's resize
policy and the follow code does this:

            if (slave)
            {
                if (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;
                    }
                }
                else
                {
                    switch(camera->getProjectionResizePolicy())
                    {
                        case(osg::Camera::HORIZONTAL):
camera->getProjectionMatrix() *=
osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break;
                        case(osg::Camera::VERTICAL):
camera->getProjectionMatrix() *= osg::Matrix::scale(1.0,
aspectRatioChange,1.0); break;
                        default: break;
                    }
                }
            }
            else
            {
                Camera::ProjectionResizePolicy policy = view ?
view->getCamera()->getProjectionResizePolicy() :
camera->getProjectionResizePolicy();
                switch(policy)
                {
                    case(osg::Camera::HORIZONTAL):
camera->getProjectionMatrix() *=
osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break;
                    case(osg::Camera::VERTICAL):
camera->getProjectionMatrix() *= osg::Matrix::scale(1.0,
aspectRatioChange,1.0); break;
                    default: break;
                }
            }

I've tried this out with your modified osgviewer example and it works
a treat fixing the problem that was otherwise visible when resizing
the window.

I've now checked this fix into svn/trunk and the OSG-2.8 branch.

Robert.


On Thu, May 7, 2009 at 3:42 PM, Cory Riddell <[email protected]> wrote:
> Hi Robert,
>
> Thanks for looking into this so closely. I've attached a small example
> program that demonstrates the problem my change fixes (IMHO). The example
> code is just osgViewer modified to add a background gradient.
>
> Start the program with --window:
>   osgViewer --window 100 100 900 600 cow.osg
>
> Everything looks good. Then resize the window. If you make the width
> relatively larger, the OSG blue peeks through on the sides. The ABSOLUTE_RF
> setting of the background slave is being ignored. Here's the original code:
>
> 01: // if aspect ratio adjusted change the project matrix to suit.
> 02: if (aspectRatioChange != 1.0)
> 03: {
> 04:    osg::View* view = camera->getView();
> 05:    osg::View::Slave* slave = view ? view->findSlaveForCamera(camera) :
> 0;
> 06:
> 07:    if (slave &&
> (camera->getReferenceFrame()==osg::Transform::RELATIVE_RF))
> 08:    {
> 09:        switch(view->getCamera()->getProjectionResizePolicy())
> 10:        {
> 11:            case(osg::Camera::HORIZONTAL): slave->_projectionOffset *=
> osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break;
> 12:            case(osg::Camera::VERTICAL): slave->_projectionOffset *=
> osg::Matrix::scale(1.0, aspectRatioChange,1.0); break;
> 13:            default: break;
> 14:        }
> 15:    }
> 16:    else
> 17:    {
> 18:        Camera::ProjectionResizePolicy policy = view ?
> view->getCamera()->getProjectionResizePolicy() :
> camera->getProjectionResizePolicy();
> 19:        switch(policy)
> 20:        {
> 21:            case(osg::Camera::HORIZONTAL): camera->getProjectionMatrix()
> *= osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break;
> 22:            case(osg::Camera::VERTICAL): camera->getProjectionMatrix() *=
> osg::Matrix::scale(1.0, aspectRatioChange,1.0); break;
> 23:            default: break;
> 24:        }
> 25:    }
> 26: }
>
> The test at line 7 will fail because the background slave has ABSOLUTE_RF.
> At line 18, policy will be set to the main camera's projection resize
> policy, not the slave camera's policy (view is not null). The code in the
> switch statement scales the slave cameras projection matrix according to the
> main cameras policy setting. Is this really how it should work, or am I
> misreading this code?
>
> Thanks,
> Cory Riddell
>
> Robert Osfield wrote:
>
> HI Cory,
>
> I have just done a review of your changes against the original code
> and I believe the original code is correct and your changes will break
> correct code.
>
> If a slave camera has an ABSOLUTE_RF then it by default will have it's
> aspect ratio adjusted.  This is correct behavior.
>
> If you don't with a slave camera to have it's aspect ratio adjusted
> then you should disable this by setting the slave Camera's
> ProjectionResizePolicy.
>
> If you review the code block in question you'll see that you can
> disable this resize.
>
> Robert.
>
> On Tue, May 5, 2009 at 12:11 AM, Cory Riddell <[email protected]> wrote:
>
>
> Robert,
>
> When you add a slave camera with ABSOLUTE_RF, the aspect ratio change
> code in GraphicsContext.cpp would ignore the slave camera's setting and
> always take the master camera's setting.
>
> The attached GraphicsContext.cpp file is from the trunk and changes only
> 3 lines.
>
> Cory Riddell
>
>
>
>
>
> _______________________________________________
> 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
>
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to