Hi Jesper, I'm not a windows developer so can't help with MFC specific issues, but I'll try to comment on the OSG specific questions:
On Tue, Sep 30, 2008 at 3:32 PM, Jesper D. Thomsen <[EMAIL PROTECTED]> wrote: > When debugging the application I noticed that the > viewer-view-_slaves-[0]-_projectionOffset-_mat-[0]...[3]-[0] values change > from their initialisation from "addslave" to "-1.#IND00000000000" right > after i dispatch the rendering thread. This off course causes further > problems in frame() with other values going bad. I couldn't really understand what you meant by "viewer-view-_slaves-[0]-_projectionOffset-_mat-[0]...[3]-[0] values", if I'm confused then no doubt others will be confused too. > My question is whether OSG could be doing this, or if it must be the > original application writing somewhere it shouldn't? Or does OSG use som > standard OpenGL variables which might be overwritten by the existing > application? OpenGL doesn't really have variables in the sense that a conventioanl API would have, it's a state machine, where you pass data and tokens into queue, and then very occasionally get data back, but this get operation typically requires a round trip to the graphics card. Given this context we aren't talking about variable, but OpenGL state, which leads us on the to question are you setting any OpenGL state in your application on the context that you are letting the OSG create within your MFC window? If you don't then the OSG will have complete control over state and shouldn't have any issues, if you do change OpenGL state on the context prior to the viewer frame() being called then you could screw up rendering as the OSG's lazy state updating mechanism won't know to correct state changes that you've made unless you tell it. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
