Re: [osg-users] X11 Trouble, Building OSG with OpenGL ES 2.0
Chris, I've also done some work toward pure EGL support, intending to improve support for Android in OSG. How far along is your EGL work? I've got most of the EGL context and surface management done in implementations of osg::GraphicsContext::WindowingSystemInterface and osgViewer::GraphicsWindow. I could separate the pure EGL calls from my Android-specific code to create a osgViewer::GraphicsWindowEGL that implements closeImplementation() makeCurrentImplementation() realizeImplementation() releaseContextImplementation() swapBuffersImplementation() Then, it would be straightforward to subclass GraphicsWindowEGL to make a GraphicsWindowAndroid or a GraphicsWindowLinuxEGL that would implement the remaining virtuals like GraphicsWindow::checkEvents(). Thoughts? James Athey APX Labs From: Chris Hanson mailto:xe...@alphapixel.com>> Reply-To: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org>> Date: Monday, October 15, 2012 10:14 AM To: "osg-users@lists.openscenegraph.org<mailto:osg-users@lists.openscenegraph.org>" mailto:osg-users@lists.openscenegraph.org>> Subject: Re: [osg-users] X11 Trouble, Building OSG with OpenGL ES 2.0 my current system is running with a X11, but it would be nice just to kick it? Did you get it running without x11? Yes. However, there was a lot of OSG Windows and Linux support code that needed writing and updating in order to support pure EGL calls (instead of EGL calls that also rely on X11), so we ended up creating the EGL context outside of OSG and using osgViewerEmbedded, which worked ok. If you're interested in having full and proper EGL support, we could possibly pick up the work I began, and finish it in a reasonable amount of budget. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com<mailto:xe...@alphapixel.com> http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Make osg::discardAllGLObjects() also discard shaders?
How do I get OSG to re-create all GL objects in response to the GL context
being recreated?
I'm trying to get my Android GLES2 app to gracefully handle switching to/from
the Activity where OSG is running, as well as to handle sleep/wake. Whenever
these happen, the EGL context is lost, and all GL objects (buffers, textures,
programs, etc.) are silently deleted.
Therefore, the usual approach is to call glGen*() when the EGL surface is
recreated. Calling glDelete* is counter-productive; the GL objects are already
gone.
I've tried using osg::discardAllGLObjects(), thinking that this will force OSG
to regenerate the GL objects during the next frame(). It appears to correctly
discard the VBOs and texture objects, but it does not discard shaders or
programs.
Code:
void osg::discardAllGLObjects(unsigned int contextID)
{
#ifdef OSG_GL_DISPLAYLISTS_AVAILABLE
osg::Drawable::discardAllDeletedDisplayLists(contextID);
#endif
#ifdef OSG_GL_FIXED_FUNCTION_AVAILABLE
osg::FragmentProgram::discardDeletedFragmentProgramObjects(contextID);
osg::VertexProgram::discardDeletedVertexProgramObjects(contextID);
#endif
osg::GLBufferObject::discardAllBufferObjects(contextID);
osg::Texture::discardAllTextureObjects(contextID);[/b]
osg::FrameBufferObject::discardDeletedFrameBufferObjects(contextID);
osg::Program::discardDeletedGlPrograms(contextID);
osg::RenderBuffer::discardDeletedRenderBuffers(contextID);
osg::Shader::discardDeletedGlShaders(contextID);
osg::OcclusionQueryNode::discardDeletedQueryObjects(contextID);
}
As you can see, this function will discard shaders and programs which have
already been deleted, but as far as OSG knows, none of them have been deleted.
The textures and buffers each have centralized managers, but the shaders and
programs do not.
How should I approach this problem? Is there a straightforward way to fix
osg::discardAllGLObjects() so that it will discard all GL shader objects? Do I
need to track all of my osg::Shader instances myself so I can call
Shader::releaseGLObjects() and Shader::dirtyShader()?
Thanks,
James
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49231#49231
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android: Problem with static intialization in osgViewer/Scene.cpp (from r13031)
Robert, It's working on my GLES 2 app as well. Thanks, James -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48599#48599 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android: Problem with static intialization in osgViewer/Scene.cpp (from r13031)
+1 I had to revert this change as well to get the latest SVN rev (r13093) to run without crashing on Android. FWIW, there is nothing wrong with static initialization on Android, and the change to Scene.cpp is definitely a bug. Without compiler specific directives, there is no way to ensure that static variables will be initialized in any particular order. (AKA the Static Initialization Order Fiasco.) Thanks, James -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48365#48365 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
