Hi again... Two things of which the first is of higher priority...
1. To make the ModelView matrix match the osg definition (z-up) how would you recommend that I calculate the modelview assuming that only the Camera is known in a preDrawCallback, just so that I don't make any assumptions that can later be changed in some other part of the system? I can get the ViewMatrix, I can also get the MatrixList (of all matrices above the camera in the scenegraph), but to match osg and to make it as flexible as the rest of osg, how would do this? 2. Regarding GraphicsContext, assume that I do need access to a graphicsContext in a PreRender, how can I take control of that Context avoiding any race condition? Now, Im not sure where I get the hang, but it does have something to do with the fact that Im accessing OpenGL when I should not... Eventhough, when I get into the PreRender callback the Context is active. so a simple makeCurrent() would not work. On 8/2/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > 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 > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- ________________________________________________________________ Anders Backman Email: [EMAIL PROTECTED] HPC2N/VRlab Phone: +46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
