Hi Anders, On 8/2/07, Anders Backman <[EMAIL PROTECTED]> wrote: > Now I stumbled on a few things. > > 1. I use to have a Producer::CameraCallback attached to the camera > that I hooked up as a preDrawCallback. > > In that callback, the OpenGL Projection, ModelView and View matrix > were all available through OpenGL calls. > > Now with osg::Camera using the same mechanism, the call: > > glGetDoublev(GL_MODELVIEW_MATRIX, m_modelview_matrix.ptr()); > > > Returns an identity matrix. > That is the OpenGL state is not yet available in the callback. > Im guessing this is applied later on, perhaps in the renderbin?
The OSG doesn't apply any matrices till it needs to, and leaves the setting of the modelview matrix till is starts rendering the leaves on the render graph - so this is after the pre draw callback of a camera. In the case of Camera pre DrawCallback the actual camera itself is passed into the callback functor so you should be able to use this directly. Also as a general guide try to avoid doing glGet's in an OpenGL application as this can stall the graphics pipineline. > As the callback is not a Visitor (!) I cant really use > computeLocalToWorldMatrix() to get the modelmatrix to concatenate this > into the ModelView either... > > So I can easily get the Projection and the View Matrix, but not the > ModelMatrix in the preDrawCallback(). > > Any suggestions? > Im guessing the reason for this redesign is the new threading models, > which is my next question... Noting setting the modelview matrix until needed is something that OSG has done since its earliest days. The fact that you glGet code worked is merely down to Producer setting the matrices, and the way the OSG works these settings were ignored anyway. > 2. Im doing Haptic rendering (force rendering using a Phantom) and for > this I'm using OpenHaptics which is sort of tapping into OpenGL for > accessing rendered primitives for extracting what to render haptically > (force rendering). > This makes it sensitive to having OpenGL Contexts generated in > different threads than the Context for the haptic devices... > > > With the new threading models only two works as I designed OpenHaptics > right now: > > OK: --CullDrawThreadPerContext > OK: --SingleThreaded > > Hangs: --CullThreadPerCameraDrawThreadPerContext > Hangs: --DrawThreadPerContext > > The questions is really, in what thread are the OpenGL Contexts > created for the various threading models? > It looks like its done in the main thread for the first two? The contexts are generated by the main application thread normally, its the makeCurrent when brings the context into the control of a particular GraphicsThread. The real difference with CullThreadPerCameraDrawTheadPerContext and DrawThreadPerContext is not related to the GraphicsThread, rather its that the cull is done in the main or separate threads, and extra syncronization barriers exists to marshal these threads to make sure no data gets overwritten when its not safe. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
