OSG for Android Beginner Tutorial series (ii)--project configuration

In the previous tutorial, I focused on compiling the OSG source code into a library of functions that can be used under Android projects. In this tutorial, I'll explain in detail how to configure the OSG function library in my Android project.

At this stage of the online about osgfor android Configuration tutorial There are many, but most of the actual use will be more or less a number of problems, can not be completely copied, the need for certain changes. Also, few people can explain the specific meanings of those variables in the configuration. This is very detrimental to the novice's learning and understanding, often resulting in a bug after the face full screen error log completely a blank face.

So I'll explain in detail in this tutorial how to configure the OSG function library in Android projects and explain the meanings of each configuration variable in detail.

-------------------------------------------------------------------------------------------------

Configuring a library of functions in a project is the first thing we do almost everything we do in project development. It can be said that a variety of third-party function libraries to help us complete a lot of common common functions, so that we from the complex basic algorithms, basic functions, and can be more focused on the implementation of the business functions we need to achieve. OSG is a very good open-source three-dimensional engine that provides a set of mature APIs for the development of three-dimensional scene functions.

First, tool preparation

OSG is a C + + platform-based API that is used in the development of standard C + +. As we all know, the development of Android projects, we usually use Java, then, how to call OSG in the Java language of these C + + functions? Java native interfaces, or JNI (Java Native Interface), are available in Java. JNI is a protocol used to communicate Java code and local C + + code. Google has developed a set of tools for Android to quickly create Native projects, the NDK (Native development Kit). In this article, configuration development is done using the ECLIPESE+NDK approach. There are many experience tutorials on the Internet that are used in Cygwin. However, the Cygwin is included from the R7 version of the NDK, so this article does not use Cygwin alone when configuring the project.

The NDK version used here is r10d, which can be downloaded on the official website and linked to:

http://developer.android.com/tools/sdk/ndk/index.html .

Of course, for some reason, now in many cases is not connected to this site, such as I am. But now a lot of web disk share can be downloaded, you can search for yourself. OSG function library can be compiled according to my previous tutorial, but the time spent relatively large, of course, can also download from the Internet Other people have compiled the OSG function library, so save time and effort. Here I am using the OSG version 3.0.1. It should be noted that in the previous tutorial, according to the parameters at compile time, there will be two versions of the OSG library, namely, GLES1 and GLES2, the two versions when used, the configuration parameters will be different, even for the novice to produce some inexplicable error. The specific difference, I will explain in detail.

Second, the specific configuration

First of all, in order to use C + + in the project, the project structure will be a little different, you need to add a JNI folder, its location at the root of the project, and SRC and other files folder on the same layer. This folder is used to store all C + + files, as well as the project configuration file (. mk suffix). This is explained in detail below.

1. Configuration files

In OSG for Android project, there are two configuration files, one is android.mk and the other is application.mk. These two files are stored in the JNI folder and are used to provide configuration information when compiling a project.

First, let's look at how the Android.mk file is configured.

Local_path: = $ (call My-dir) include $ (clear_vars) Local_module: = Osgnativelib#osg_android_dir: = D:/mytools/osggles2_3 _0_1osg_android_dir: = D:/mytools/osggles1_3_0_1libdir: = $ (Osg_android_dir)/obj/local/armeabiifeq ($ (TARGET_ARCH_ ABI), armeabi-v7a) Local_arm_neon: = True Libdir: = $ (Osg_android_dir)/obj/local/armeabi-v7aendif### Add al L source file names to being included in Lib separated by a whitespacelocal_c_includes:= $ (osg_android_dir)/includelocal_cfla GS: =-fno-short-enumslocal_cppflags: =-dosg_library_staticlocal_ldlibs: =-L $ (sysroot)/usr/lib-llog#local_ldlibs + =-L $ (sysroot)/usr/lib-lglesv2local_ldlibs + = L $ (sysroot)/usr/lib-lglesv1_cmlocal_ldlibs + = L $ (sysroot)/usr/lib-l Zlocal_ldlibs + = L $ (sysroot)/usr/lib-gnustl_staticlocal_ldlibs + =-landroidlocal_src_files: =osgMain.cpp OsgNativeLib.cpp modelUtil.cpp AnimationUtil.cpp externvariables.cpplocal_ldflags: =-L $ (libdir)-losgdb_dds-losgdb_ Openflight-losgdb_tga-losgdb_rgb-losgdb_osgterrain-losGdb_osg-losgdb_ive-losgdb_deprecated_osgviewer-losgdb_deprecated_osgvolume-losgdb_deprecated_osgtext-losgdb_ Deprecated_osgterrain-losgdb_deprecated_osgsim-losgdb_deprecated_osgshadow-losgdb_deprecated_ Osgparticle-losgdb_deprecated_osgfx-losgdb_deprecated_osganimation-losgdb_deprecated_osg-losgdb_serializers_ Osgvolume-losgdb_serializers_osgtext-losgdb_serializers_osgterrain-losgdb_serializers_osgsim-losgdb_ Serializers_osgshadow-losgdb_serializers_osgparticle-losgdb_serializers_osgmanipulator-losgdb_serializers_ Osgfx-losgdb_serializers_osganimation-losgdb_serializers_ Osg-losgviewer-losgvolume-losgterrain-losgtext-losgshadow-losgsim-losgparticle-losgmanipulator-losgga-losgfx-losgdb-losga Nimation-losgutil-losg-lopenthreads-lgnustl_static-lgdalinclude $ (build_shared_library) #include $ (BUILD_STATIC_ LIBRARY)

Each configuration variable is explained in detail below.

Local_path: This variable is used to find the source file in the project tree. In this example, it is configured as $ (call My-dir), which is a macro function that is provided by the compilation system to return the current path, that is, the path containing the android.mk file;

Include $ (clear_vars): This configuration means that the configuration of variables before emptying all local_xxx except Local_path. As can be seen, we need to configure the variables must be in this configuration statement after the, or even if configured, it will be emptied out of this sentence;

Local_module: This variable represents the name of the module that the profile describes, and the name is unique. And this configuration variable must be configured. During the compiling process, the compiler automatically generates the name of the library dynamic library according to this variable, in general, the generated dynamic library will be named libxxx.so, where xxx is the name of the local_module variable configuration;

Osg_android_dir: This configuration variable represents the location of the OSG, which is the location of the compiled OSG. In this example, I wrote two paths, one of which was commented out by the #. As I mentioned before, OSG for Android at compile time according to different parameters, will produce two versions, respectively, GLES1 and GLES2, The two versions of OSG in the configuration is different, here is one of the different points;

Libdir: This configuration variable is the location that points to the OSG library, looking down at the location of the static library based on the OSG location pointed to by Osg_android_dir. In fact, if we open this folder, we can find a series of files with the suffix. A, these files are the static library of OSG. The next four lines of code are used to determine the target ABI (i.e. the application binary interface) and reconfigure the static library location based on the results of the decision.

Local_c_includes: This variable points to the Include folder for the corresponding version OSG, which specifies the location of the OSG header file;

Local_cflags: This variable is an optional set of variables for additional compilation options. When writing a configuration file, you can copy the settings here, without modification;

Local_cppflags: Similar to the previous variable, the difference is that this variable is used to set up CPP file compilation, from the literal meaning can be seen, ibid, can be copied.

Local_ldlibs: Used to add a system. Watch out! when configuring this variable, there is a difference in the configuration of the GLES1 and GLES2 two versions, which is the second different place. In particular, it is important to note that when you choose to use the GLES1 version of OSG, the variable is configured with -lglesv1_cminstead of taking it for granted-lglesv1! Beginners are prone to make this mistake when they first touch, and it's hard to notice. The rest can be copied.

Local_src_files: Here is a list of C and CPP files that need to be compiled into the dynamic library. As long as the use of C or CPP files to be added, the compiler system will be based on the value of this variable to find files, if not added, the compilation system can not find the corresponding files, it will cause compilation errors.

Local_ldflags: This configuration variable is similar to the LOCAL_LDLIBS variable function and is also used to add system libraries.

Include $ (build_shared_library): This code means that the module is defined as a dynamic library, the. so file. In this example, there is a sentence that is commented out by the # include $ (build_static_library), which specifies that the module generates a static library, which is a. a file.

　　

Let's look at another configuration file, the configuration method for the Application.mk file.

App_build_script: = $ (call my-dir)/android.mkapp_optim: = Releaseapp_platform: = Android-10app_stl: = gnustl_staticAPP_ Cppflags: =-fexceptions-frttiapp_abi: = Armeabi armeabi-v7aapp_modules     : = Osgnativelib

Each variable is explained in detail below.

App_build_script: This variable will look for android.mk under the current path, which is the Mk file we configured earlier;

App_optim: This is an optional variable whose value can be set to release or Debug. When set to release, will generate highly optimized binary code, and when set to debug, generated is not optimized binary code, but can detect a lot of bugs, can be used for debugging;

App_platform: This variable is used to set the minimum running platform of the project, it is important to note that there are many tutorials on the web, the android-8 is set here, but according to my test, if set to Android-8, there will be some errors that can not find the file, but set to android-10 above , it can compile normally;

APP_STL: This variable is set to Gnustl_static, which means using the GNU libstlc++ as a static library;

App_cppflags: This variable is used to set up a C + + compiler switch collection that is passed when compiling any C or C + + source code for any module. It can be used to change the build of a module that a given application needs to rely on, rather than modifying its own android.mk file;

App_abi: Used to set the binary interface, Armeabi by default, Armeabi and armeabi-v7a are set in the examples in this article. Watch out! There are examples on the internet here at the same time set up the x86, according to my test, plus x86 will produce the NDK abortting Stop error, so, do not add -x86;

App_modules: This variable lists the module names required for compilation. The module name is the value of the local_module that we previously set in the Android.mk file.

2. NDK Builder Configuration

in Project view on the left of Eclipse, right-click the project you want to set and select Properties:

After entering, select Builder on the left side of the interface, then click the New button of the interface zip:

Select Program in the Choose Configuration Type interface and click OK. ：

In the setup interface that appears, in the Main tab, location is set to the current project under the installation directory for the NDK that you are using nkd-build.cmd;working directory. On the Refresh tab, tick the refresh resources upon completion. In the Build Options tab, tick specify working set of relevent resouces, and click the Specify Resouces button to select the Jni folder for the current project.

3. Configuration in Java

The configuration in Java is relatively simple, but it is also easy to forget. Since the OSG window displayed on Android is based on Glsurfaceview, it is important to note that when creating the Glsurfaceview, you should base the version of GL on Glsurfaceview for the OSG versions you use. This configuration requires only one line of code:

Myglsurfaceview.seteglcontextclientversion (1);

　　 because the GLES1 version of the OSG library is used in my example, the value here is set to 1, so if you are using the GLES2 version of the OSG library, set it to 2. This is a relatively easy place to forget.

Iii. Summary

As far as I know, many novice osg for Android have encountered one or more of these problems when configuring a project, as I did when I first approached it. Most of the problem is that the content of this configuration is not very familiar with the meaning of it, so will not know what to do after the problem. I summed up a bit of error-prone areas.

1. Add or subtract spaces

In the Mk file, it seems very sensitive to spaces. Many of us consciously or unconsciously will be accustomed to play space, especially at the end of a line of code, it is easy to more than one space. However, this situation can cause errors in the Mk file. When I first approached, I tried to look at the space line by row to see if there were any superfluous or missing spaces;

2. When using the GLES1 version of the library, the-lglesv1_cm error

Perhaps when you see some examples of using the GLES2 version of-lgles2, it is assumed that using the GLES1 version is directly set to-lgles1. As a result, errors are found at compile time. And the error does not point directly here, but there will be some can not find the OSG header file errors, will make people very confused. In fact, this kind of error is very likely to appear here.

3.-x86 's error

I've seen some tutorials mentioned above, the NDK has some problems with x86 compatibility, but there are still a few examples with-x86. My advice here is not to add-x86 behind the App_abi of the application.mk file.

---------------------------------------------------------

The next article in the OSG for Android tutorial will explain in detail a helloworld example of how to run the simplest OSG for Android program with a simple example. Please pay attention.

OSG for Android Tutorial series (ii)--project configuration