Re: [osg-users] View/Projection/ModelView matrix not applied?
Hi Anders, On 8/3/07, Anders Backman [EMAIL PROTECTED] wrote: 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? The OSG us of z up is merely a convention used by the camera manipulators and the loaders, the view matrix itself encodes this for you, there isn't any other matrix added in behind the scenes by the OSG, so its exactly what is passed to OpenGL. So... I would have though just passing the view matrix as is would the appropriate thing to do. 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? With Viewer cameras there aren't any nodes above it so this should just be an empty lists. 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. The Camera pre draw callback will have the graphics context already made current so there won't be any need to call makeCurrent yourself. If you are finding problems doing OpenGL calls in a Camera pre or post draw callback then there must be something else wider that is amiss - the OSG itself should be having the same problems too. As for hangs or race conditions on your own code, I can't really comment. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] View/Projection/ModelView matrix not applied?
So... I would have though just passing the view matrix as is would the appropriate thing to do. Yes, thats right. The problem for me in this case was that I expected, and required the OpenGL view states to be set at the point of the preDrawCallback for a camera. The reason for this is that OpenHaptics, the haptic rendering toolkit which Im depending on is reading the OpenGL modelview matrix during its pre-haptic-draw. This gets event more complicated as one need to follow the below described loop: Each haptic device is associated to a Camera (due to that one need the View/projection matrices setup before rendering). 0. Draw Haptic Scene 1. for each haptic_device: 1.1 Apply view/projection for associated osg::Camera 1.1 haptic_device-makeCurrent() 1.2 haptic_device-beginDraw() 2. render opengl (any valid geometry call will be caught by haptic API as haptic geometry) 3. Finished: for each camera 3.1 haptic_device-endDraw() Now if the modelview matrix is applied within the renderbin, just before a Leaf is about to be rendered, one has to initialize the haptic rendering there. I do have a HaptiCrenderbin, and HapticRenderLeaf already so that structure is working. The problem is now that the ModelViewMatrix can be pushed/popped several times due to the accumulated state for a RenderLeaf, so there is nowhere I can put my haptic_device-beginDraw() where I know that: Here is where the ModelView matrix is applied to OpenGL. In osg1.x together with Producer, the OpenGL states were applied before the PreDrawCallback, but as you pointed out, that state-change was effectively ignored by OSG. Now I have to decorate the scene with a mechanism that before the haptic part of a scene-graph is rendered, it has to begin the haptic rendering WITH a valid OpenGL context and the correct ModelView matrix applied. I cant really see how I am going to achieve that with callbacks, or even my own RenderBin... I could try to collect all the haptic devices to the HapticRenderBin and try to initialize them there. But thats not really what I am after, I want to associate the HapticDevice to the camera, so that when the scene for a specific camera is about to be drawn, the hapticdevice is properly initialized and used too. I thought preDrawCallback would work like that, but I realize that it doesnt anymore, which is probably a good thing for performance, but less good for me ;-) Does anything of this make sense? Im not sure how to hook the haptic rendering into osg2.0 as it is right now. Any input is appreciated, cheers, Anders 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? With Viewer cameras there aren't any nodes above it so this should just be an empty lists. 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. The Camera pre draw callback will have the graphics context already made current so there won't be any need to call makeCurrent yourself. If you are finding problems doing OpenGL calls in a Camera pre or post draw callback then there must be something else wider that is amiss - the OSG itself should be having the same problems too. As for hangs or race conditions on your own code, I can't really comment. 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
Re: [osg-users] View/Projection/ModelView matrix not applied?
Hi Anders, I don't quite understand the problem. A pre draw callback gives you the Camera, and it has the view and projection matrix, it has everything you need. If the OpenHaptic library requires a matrix set by OpenGL then just set it then and there in your pre draw callback. Robert. On 8/13/07, Anders Backman [EMAIL PROTECTED] wrote: So... I would have though just passing the view matrix as is would the appropriate thing to do. Yes, thats right. The problem for me in this case was that I expected, and required the OpenGL view states to be set at the point of the preDrawCallback for a camera. The reason for this is that OpenHaptics, the haptic rendering toolkit which Im depending on is reading the OpenGL modelview matrix during its pre-haptic-draw. This gets event more complicated as one need to follow the below described loop: Each haptic device is associated to a Camera (due to that one need the View/projection matrices setup before rendering). 0. Draw Haptic Scene 1. for each haptic_device: 1.1 Apply view/projection for associated osg::Camera 1.1 haptic_device-makeCurrent() 1.2 haptic_device-beginDraw() 2. render opengl (any valid geometry call will be caught by haptic API as haptic geometry) 3. Finished: for each camera 3.1 haptic_device-endDraw() Now if the modelview matrix is applied within the renderbin, just before a Leaf is about to be rendered, one has to initialize the haptic rendering there. I do have a HaptiCrenderbin, and HapticRenderLeaf already so that structure is working. The problem is now that the ModelViewMatrix can be pushed/popped several times due to the accumulated state for a RenderLeaf, so there is nowhere I can put my haptic_device-beginDraw() where I know that: Here is where the ModelView matrix is applied to OpenGL. In osg1.x together with Producer, the OpenGL states were applied before the PreDrawCallback, but as you pointed out, that state-change was effectively ignored by OSG. Now I have to decorate the scene with a mechanism that before the haptic part of a scene-graph is rendered, it has to begin the haptic rendering WITH a valid OpenGL context and the correct ModelView matrix applied. I cant really see how I am going to achieve that with callbacks, or even my own RenderBin... I could try to collect all the haptic devices to the HapticRenderBin and try to initialize them there. But thats not really what I am after, I want to associate the HapticDevice to the camera, so that when the scene for a specific camera is about to be drawn, the hapticdevice is properly initialized and used too. I thought preDrawCallback would work like that, but I realize that it doesnt anymore, which is probably a good thing for performance, but less good for me ;-) Does anything of this make sense? Im not sure how to hook the haptic rendering into osg2.0 as it is right now. Any input is appreciated, cheers, Anders 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? With Viewer cameras there aren't any nodes above it so this should just be an empty lists. 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. The Camera pre draw callback will have the graphics context already made current so there won't be any need to call makeCurrent yourself. If you are finding problems doing OpenGL calls in a Camera pre or post draw callback then there must be something else wider that is amiss - the OSG itself should be having the same problems too. As for hangs or race conditions on your own code, I can't really comment. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] View/Projection/ModelView matrix not applied?
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
[osg-users] View/Projection/ModelView matrix not applied?
Hi. Im updating osgHaptics to reflect the latest changes in osg and also to remove dependency of Producer in the core osgHaptics library. Im welcoming the new Camera model instead of having 3-5 places storing a View/Projection matrix! Thanks for that Robert! 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? 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... 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? Cheers, Anders -- -- 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
Re: [osg-users] View/Projection/ModelView matrix not applied?
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
