Hi Jorge, Thanks for the explanation on Android version and viewer status.
Could you or Rafa add a mention Android support into the OpenSceneGraph/README.txt and a READEME.txt in the Android example application that point users to what is what. For an directory/application I'd suggest something like osgviewerAndroidGLES1 or simply osgviewernAndroid. With thie README.txt's in place I think the example would be ready to check into OSG svn/trunk. Thanks to Rafa and yourself for your efforts on Android, Robert. On Fri, Mar 11, 2011 at 8:40 PM, Jorge Izquierdo Ciges <[email protected]> wrote: >> Do you see any opportuinties for centralizing the setup so that other >> codes could reuse them, or do you think we'll need to include a >> similar amount of set up code for all Android applications? > > I see it hard as it is right now. Robert until Android 2.3 and 3.0 get in > the market the people will deliver their applications an will want to do > them to work in 2.1/2.2 Android. Unlukly of us only 2.3 and 3.0 have a > Native Activity class that can be centralized. For those it will be easy to > make a osgAndroidActivity class with all the ups and downs that has Android > and with the ability to have context initialized. In a future line (because > debugging and testing osg in emulator is really difficult practically > impossible) it was one of our thoughts. > But for those older systems they need the same amount as code as you've > seen. They need a Java part that makes Activity, a part that does EGL > context and a Jni part to expose everything you want to expose of your C++ > application. Inside the C++ code the setup is really small and works > withouth context (we haven't found any way to pass it). The good news is > that our code can be reused a 100% for small applications. Bigger > applications with other needs than a keyboard and multitouch input probably > will need to code other Activities or some new JNI from C to Java. >> >> The automatic GLES2 shader generation which to to provided some basic >> rendering functionality out of the box is not actually written for >> GLES2, instead it crudely reuses the osgUtil::ShaderGenVisitor that >> convertes fixed function scene graphs into GLSL shader based >> equivilants. The GLSL code is OpenGL 2.0 spec though, so might well >> be the source of problems if you are relying upon this. >> > > Yes that something that Rafa and I were expecting and that's why we didn't > rely too much upon them. The main trouble was that every OpenGL ES command > was pointed to null so i changed the code in GLExtensions to do a proper > call to the library and fixed it. I'm waiting to Rafa to check it out. I was > also thinking until there were a better solution to the context trouble to > make the call for OpenGL and GLSL version to return some standard values. > Right now they return a pretty 0. > I didn't properly test the automated shaders but the biggest issue they had > was the lack of a precission instruction at the begin of the code. With that > instruction it could be compiled the shader probably. > > Thanks for all ^^ > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
