Hi,
I've implemented Robert's recommendation of using a cull visitor,
code attached below. The matrix I'm getting from the cull visitor
doesn't appear to have been modified by the near/far plane code. I've
visually verified that the near and far planes are actually being
moved around, but am at a loss as to why I'm still getting the
original matrix back.
class WriteProjectionMatrixToUniformCallback : public osg::NodeCallback
{
private:
osg::ref_ptr<osg::Uniform> _uniform;
public:
WriteProjectionMatrixToUniformCallback(osg::ref_ptr<osg::Uniform>
UNIFORM) { _uniform = UNIFORM; }
virtual ~WriteProjectionMatrixToUniformCallback(void) {}
virtual void operator()(osg::Node* NODE, osg::NodeVisitor* NV)
{
NodeCallback::traverse(NODE, NV);
osgUtil::CullVisitor *cv =
dynamic_cast<osgUtil::CullVisitor*>(NV);
if(cv == NULL) return;
osg::Matrix m = *(cv->getProjectionMatrix());
if(_uniform != NULL) _uniform->set(m);
float n = (m(3, 2) +m(3, 3)) /(m(2, 2) +m(2, 3));
float f = (m(3, 3) -m(3, 2)) /(m(2, 3) -m(2, 2));
std::cout << "n = " << n << ", f = " << f << "\n";
}
};
Does anyone have an idea what I might be doing wrong? Am I right to
call traverse before I deference the pointer to the matrix? Am I
getting a pointer to the right matrix?
Alan
On 4 Dec 2007, at 17:13, Robert Osfield wrote:
> Hi Alan,
>
> On Dec 4, 2007 4:20 PM, Alan Purvis <[EMAIL PROTECTED]> wrote:
>> I am using OSG 2.2, though I'm still using the depreciated names for
>> some of the OSG classes, sorry. I really should grep the code (and my
>> brain) to sort that one out.
>
> Confusion reigns... now a bit clearer.
>
>> My use of 2.2 comes with caveat that I can't use the new Viewer
>> classes and am manually managing the windowing code, OpenGL context
>> and SceneView(s). The project I'm working on was originally created
>> to work with osg < 0.95 and there are certain legacy requirements as
>> a result. It would be a lot of work to rip all that code out of the
>> project and tack the osg Viewer stuff on, especially since project's
>> structure was originally designed and tailored with the old SceneView
>> semantics in mind. That said I might get around to it some time when
>> there's less work to be done elsewhere! OSG evolves at such a pace
>> it's hard for a one man project to keep up!
>
> The embedded viewer functionality of osgViewer that is used in
> examples like osgviewerGLUT and osgviewerSDL should map well to apps
> that current use SceneView.
>
>> The cull callback idea you suggest sounds like the right approach. If
>> I grab the matrix in this way is it safe to update the value of a
>> uniform attached to a "higher camera" from within the cull phase? I
>> know you're not really supposed to touch the graph between updates,
>> culls and draws, but perhaps such a small change is ok? If it's legal
>> to do so, then I think this should solve my problem quite elegantly.
>> I knew the correct matrix was floating around the scenegraph at some
>> stage during the cull and draw phases, just finding it was the
>> problem!
>
> The only problem with changing the scene graph in cull or draw is that
> it can cause threading issues, but if your are running single threaded
> then you won't hit upon any such issues and it should be safe.
>
>> Slightly off topic are there any plans for phasing the SceneView
>> class out in the near/distant future? If it was suddenly removed from
>> the OSG I'd be left with a lot of work to do. Is it safe to assume
>> it's going to be around for a while longer or should I try and get
>> away from it now while I'm still compatible with the current version
>> of OSG?
>
> SceneView won't be disappearing from the 2.x series of the OSG for
> backwards compatibility reasons, but its use is deprecated. Future
> rev's of osgViewer won't use SceneView but right now internally uses
> SceneView for convenience of set up of stereo extra.
>
> Robert.
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org