NAVTOR SDK  v.3.0
Software Development Kit for fast and efficient development of ECDIS, ECS and generic marine applications
Chart Rendering with OpenGL

NAVTOR SDK 3.0 uses OpenGL and OpenGL ES2 for chart rendering. OpenGL is used for desktops and OpenGL ES2 is used for embedded systems such as smartphones and other devices.

OpenGL version

NAVTOR SDK 3.0 supports OpenGL 3.0 or higher and OpenGL ES2 or higher.

System requirements

Windows

WGL platform – supports OpenGL; supports OpenGL ES2 if your display driver has the WGL_EXT_create_context_es2_profile extension.

Android

EGL platform – supports OpenGL ES2.

Linux

  • MESA – only supports OpenGL
  • EGL – supports both OpenGL and OpenGL ES2
  • GLX – supports OpenGL; supports OpenGL ES2 if your display driver has the GLX_EXT_create_context_es2_profile/GLX_ARB_create_context_profile extensions.

Application operation flow

NOTE: For OpenGL to operate, the GL context should be bound to a thread. Only calls from this thread are executed in the bound GL context. You can also share several contexts to share their resources (textures, buffers, etc.).

The general application operation flow is as follows:

  1. The application creates an application window, which can be either a software or an OpenGL (ES2) window
  2. Visman selects data according to specified parameters and transforms them to visual chart primitives.
  3. The GLSymb library prepares and draws chart primitives (areas, lines, icons, etc.).
  4. The GL2D library implements GL primitives using OpenGL. It offers two rendering options: directly to the window, or to the GL2D texture. After you have rendered, you will get either a texture, which you should draw in the application window, or the chart in the application window. If you get the texture, you also have two options: you can get binary data from it or use it directly.

OpenGL Initialization

To initialize OpenGL, use helper in C:!git\sdk.master\visualizationlayer\inc\vismangl\scene_manager_gl_helper.h SDK 3.0 implements various options for OpenGL initialization. The OpenGL initialization helper provides its CreateSceneManagerGLInitialParameters method for each initialization option.

Independent mode

If initialized this way, the GL2D component creates a required GL context together with a separate thread for it, places the context to the thread and forwards all calls to the thread. This is the most reliable option that works in all situations. However, if initialized in the independent mode, the GL2D does not share the context, which means that you cannot draw the texture directly to the window. You can take the bitmap out of the texture and upload it to another texture, and then draw the latter to the window.

Benefits: This is the only available option if the map window is a software or a DirectX window, rather than an OpenGL (ES2)-based window.

Drawbacks: This option is the slowest.

The independent initialization mode requires the following parameters for the CreateSceneManagerGLInitialParameters method:

Parameters
gl_type= Auto/OpenGL/OpenGL_ES2, if you set the gl_type value as Auto, the GL2D component choses the type automatically
sharable_context= null
ext_created_ctx= null
scene_manager_gl= null

Sharable context mode

The application creates an OpenGL window and renders the map texture to this window. You can pass the GL context of this window to the GL2D component as an initialization parameter: this way the window context is shared with the context created within the GL2D component and you can render the GL2D texture directly to the window.

Benefits: This option works faster than the independent mode option.

Drawbacks: The window context should be compatible with the GL2D context: you cannot create an EGL context and pass it to GL2D compiled to work with GLX. Such compatibility is not always possible, so it is better not to use such direct transfer of native context.

The sharable context mode requires the following parameters for the CreateSceneManagerGLInitialParameters method:

Parameters
gl_type= OpenGL/OpenGL_ES2, set the value to a specific context type, the Auto value is not an option here.
sharable_context= native context of the specified framework packed into ISDKParametersSP, see WrapContext
ext_created_ctx= null
scene_manager_gl= null

External context mode

The application creates a window with a GL context and an implementation of the IGL2DThread component for the thread that stores the GL context and passes all this to the GL2D component.

This way, GL2D does not create its own context: it uses this external context to render everything. It means that all GL-commands are placed to the IGL2DThread implementation, and the application runs the commands in an appropriate thread of the GL-context.

Benefits: The application can render directly to the window; it requires no texture. This is the fastest rendering option.

Drawbacks: It is preferable that the window is stored in a separate application thread which is sometimes difficult to implement.

The external context mode requires the following parameters for the CreateSceneManagerGLInitialParameters method:

Parameters
gl_type= OpenGL/OpenGL_ES2, set the value to a specific context type, the Auto value is not an option here.
gl2d_thread- Own implementation of IGL2DThread interface
get_gl_proc_addr- Pointer to appropriate xxxGetProcAddress method (wglGetProcAddress/eglGetProcAddress/glXGetProcAddressARB/OSMesaGetProcAddress/etc)
gl_lib_handle- Handle to appropriate OpenGL library (::GetModuleHandleA("opengl32.dll") for Windows, can be NULL for Linux)

Context created by the Application and packed to IGL2DExtCreatedGlCtx mode

Here is an example of how to use this mode. You have a QT application; thus, the context is also created through QT, rather than directly, which means that the context has a QT wrapper.

You can pull the GL context out and use the sharable context mode, or you can use an alternative option. Create a Qt GL widget that contains a GL context, then create a new Qt GL context and share it using Qt methods with the context from the Qt GL widget you have created.

Finally, wrap this newly created context with the IGL2DExtCreatedGlCtx interface and pass it to the GL2D as an initialization parameter.

What is the point of this: all GL contexts with no exception are created using the same scheme, in this case it is the Qt scheme. It means that Qt itself is in charge of creating and sharing the contexts. This method is similar to the sharable context mode, the only difference being that the GL2D does not create its own GL context, it uses a context created externally. If all goes well, the application can render the texture directly to the window, which makes it a fast rendering option.

The Context created by the Application and packed to IGL2DExtCreatedGlCtx mode requires the following parameters for the CreateSceneManagerGLInitialParameters method:

Parameters
gl_type= OpenGL/OpenGL_ES2, set the value to a specific context type, the Auto value is not an option here.
sharable_context= null
ext_created_ctx= pass here the externally created and wrapped in IGL2DExtCreatedGlCtx context (i.g. Qt-created context)
scene_manager_gl= null

Second and the following windows mode

If the application has already created a main chart window and you need another window, for example a look-ahead window, you have two options. One option is to create another window with its own set of resources and to render the map to each window independently.

Another option is to use the same GL context for one or more windows, this way most of the resources are shared.

The general application operation flow is as follows:

Several ‘window > visman > glsymb’ implementations and one GL2D with one GL context implementation.

Maps are rendered one after another.

The second window mode requires the following parameters for the CreateSceneManagerGLInitialParameters method:

Parameters
gl_type= OpenGL/OpenGL_ES2, set the value to a specific context type, the Auto value is not an option here.
sharable_context= null
ext_created_ctx= null
scene_manager_gl= Earlier created scene manager GL instance

OpenGL Implementation Features

When implementing rendering with OpenGL, take into account the following implementation features:

  1. NAVTOR SDK does not provide external renderers that can be used with OpenGL implementation to render user overlays. You can use a custom geo-database to add an overlay:

    • Fill a database with features and geometries.
    • Attach it as a source to the visualization backend
    • The SDK does all the drawing.

    This approach is limited by a small number of allowed visualization primitives: solid and dashed lines, areas filled with one of predefined colors and patterns, texts, and several predefined icons. On the other hand, you do not need to think about graphics at all, just update the database and push the rendering.

  2. Unlike Software rendering, OpenGL rendering needs no additional viewport. You can specify the center, scale, and angle of the image right before rendering. Use the ISceneControlGL::SetSceneParameters method.
  3. OpenGL rendering does not implement the following features:
    • follow vessel mode (it will be implemented in future versions of SDK);
    • scene cloning;
    • light sectors highlight;
    • adjust scale mode;
    • full light information (kPP_FullLightsInfo);
    • transparency on/off;
    • AML.
  4. OpenGL rendering implements the grounding check function and radar overlay differently.