Hi Robert (et all), I know this is a stupid question, but what does "RTT" mean?
-- Rick On 11/29/06, Robert Osfield <[EMAIL PROTECTED]> wrote:
Hi Xiaoshuxing, > I'm now using the release version 1.2, and I'm using it with the QT > windowing system. > > Now , the only way I can get something about camera is through the sceneview > object in my QOSGWidget. In CVS there is a are two QT examples osgsimpleviewerQT3 and osgsimpleviewerQT4 which might be of interest to you, they should simplify the task of intergrating the OSG with QT. > How can I get the eye position and near far clip > plane? This all depends upon when you want to querry it, at the application level, during cull traversal, during draw traversal or.... > Because I want to pass them to my GLSL fragment shader, or is there any way > to get those variables directly in the GLSL shaders? I've searched the GLSL > orange book, but all over the book, it assumes the eye position to be > (0,0,0). GLSL supports several inbuilt uniforms including gl_ModelViewProjectionMatrix and gl_ModelViewMatrix. The OSG also adds osg_ViewMatrix and osg_ViewMatrixInverse that are set per frame. Using these you should be able to do what you want entirely with GLSL without any need for extra external code. > If version 1.3 will clarify this camera thing, that'll really be great, and > I'll definitely dig into that, but for now, I can't wait a month for that. For your GLSL work nothing will change with the osgViewer library as you should already have what you from the built in uniforms, and the OSG osg_ built uniforms will be maintained tool. What the osgViewer library will resolve is that there will be just one general purpose osg::Camera, that can be used in the scene graph for RTT, HUD/multi-pass purposes or at the viewer/application level. Using a camera both in the scene graph and at the application does go against Don's model of how cameras should be used - i.e only external to the scene graph. I did once subscribe to this point of view, but in my attempts to improve RTT support in the OSG I eventually came to the realization that all the cull callbacks I was having to use to set up projection, view matrices and buffers was in essense a camera. Once I realised this it was obvious that you can't keep to dogma that cameras shouldn't be part of the scene graph - you simply can't do modern RTT work with scene graphs without them being an integral part of the scene graph. And so about a year and half ago osg::CameraNode was born. Don's article was a response to the birth of osg::CameraNode. Don is good writer so it sounds pretty compelling, but it doesn't address the a paradox that the cull callback you need to do modern RTT work actually place the camera in the scene graph. Its this paradox which breaks the camera analogy and trying to stick with it just causes confusion. Alas osg::CameraNode existing in parallel with Producer::Camera and Producer::CameragGroup/OsgCameraGroup itself has brought confusion. So while osg::CameraNode was a boon for RTT and other scene graph work (such as serialization, decoupling rendering code from applications, providing RTT fallbacks) it hasn't made understanding the various relationships easier. My hope for osgViewer is that we'll be able to untangle some of the concepts and unify the API more. One of the recently changes towards this unification was renaming osg::CameraNode to osg::Camera. More info on osgViewer can be found on the wiki: http://www.openscenegraph.org/osgwiki/pmwiki.php/Tasks/OsgViewer I am currently busy with other project work right now, but once this is complete I'll return to working on osgViewer and will open out debates about viewers then. This should commence in a couple of weeks time. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
