Hi Rutton, I'm not familiar with Andriod programming so can't help with the platform specifics, I'll try an make what suggests I can though.
If you have a EGL context already then as you've picked up using osgViewer with GraphicsWindowEmbedded is the way forward. The osgviewerGLUT and osgviewerSDL examples illustrate how this can be done. As you will see from these examples a viewer.frame(); called when you want to render each new frame. This viewer.frame() method itself calls viewer.advance() to move the FrameStamp on one frame. The FrameStamp is used to synchronize all the updates and rendering so that all objects have the same reference and simulation time for that particular frame. Next the viewer.eventTraversal() is run which updates any CameraManipulator and EventHandler attached to the viewer. Next the viewer.updateTraversal() is called to animation any objects in the scene. Finally viewer.renderingTraversals() is called that coordinates the running of the cull and draw traversals. For your usage just calling viewer.frame() will probably be appropriate. Robert. On Thu, Aug 26, 2010 at 10:50 PM, Rutton Rankin <[email protected]> wrote: > Hi, > me too, Android. > > I have a completely compiling OSG build for Android (as static library only). > I have did some mods to OpenThreads (rough... ;-), the buildsystem here and > there and added some guarded includes for Android. Even osgViewer seems to > compile just fine (I use GraphicsWindowEmbedded as dummy implementation). > > What is missing now is the connection between Android-Java and OSG. > I will explain first how GL-Setup and Rendering is done with Android. > The first steps are always done with Java, as the native kit does not support > EGL or any other window handling. It is just able to do raw openGL ES calls > (what khronos headers provide). > Well, in the Android-Java-Environment, a GLSurfaceView ist created, which > creates an EGLContext. Then, a GLSurfaceView.Renderer is attached to this > GLSurfaceView. The renderer is called in a thread-loop (in the JVM) and draws > a single frame with each call. These calls can then call (via JNI) native > implementations for drawing with a native openGL-lib. > > And thats what I need now, a way to manually request a drawing-operation for > a scene. I would start with one scene first, and see how that could work. > What I understand of osg is, that it provides always at least one thread to > do all the work (Threading-Model Singlethreaded as simplest example). Here, I > have to provide a way, to remove the actual drawing request (but still doing > event handling seems fine) and offer some way for the JVM-Render-Thread to > execute the rendering for a single frame (of the scene). > I believe, the needed modifications can be done in osgViewer, but I don't > really understand how osg starts to render a single frame, e.g. which class > calls which class (especially which class is the root for starting off to > render a frame). Okay, I will do some more rtfs, but perhaps someone can > enlighten me and give me some hints on how to do it the best way. > > Cheers, > Rutton > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=31086#31086 > > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
