Using Ogre 1.8 with JOGL and OpenGL ES 2.0

I want to use the latest version of Ogre (Ogre 1.8) and render to a SWT control using
OpenGL ES 2.0.
For this can I setup GLcanvas, GLProfile, GLCapabilites classes which are provided by Jogamp
 to setup the EGL part(window handling part) and use Ogre rendering calls through a native JNI
interface which will automatically draw the 3D part.

Basically the whole window handling part will be delegated to JOGL classes GLcanvas, GLProfile, GLCapabilites.

And the 3D drawing part will NOT be done by JOGL but will be done at the native (C) layer itself
through a seperate Java class unrelated to JOGL.

Is such a case will Ogre scene get succesfully rendered on the JOGL Surface?

I want to avoid setting up the EGL part myself without using JOGL because it seems JOGL has a lot of abstractions, classes and code related to Window Handling and it would be worthwhile not to rewrite that.

On 02/17/2012 05:33 PM, seahorse [via jogamp] wrote: Understood.

Well, if you wanted the reverse, ie use an already existing GL context etc
for rendering - we would call it an external GL context and actually have
a methodology in place :)

JOGL won't forbid you to use the current context somewhere else, sure not.
And you can make it current etc and pass all the details via JNI to
your other special binding. You could do this either for each frame
and use JOGL's frame by frame makeCurrent/release
or you could just create context and surface, hold the locks and
pass it to Ogre. As you wish ..

It's more a question whether you can satisfy Ogre or not.

~Sven

Hi

Just take care when using native calls... I mixed JOGL with legacy C/C++ source code and another crappy scenegraph which was less careful than JOGL (especially under Windows). When you don't have the choice, it's fine but in industrial context, I advise to avoid doing it. I get better performances and better reliability when using a single context with pure JOGL. As far as I know, unfortunately, there is no pure Java port of Ogre yet.

ok thanks for the response

correct me if i am wrong but
I am assuming JOGL has its EGL interface seperated out into seperate classes which is unrelated to the opengl classes.
And I am assuming these seperate classes for SWT would be
GLCanvas, GLCapabilites (set's EGL configs independent of GL)
GLWindow(set's up EGL Surface independent of GL)
and the swap buffers call - Swapbuffers
and for eglcontext?

Is there a strict one to one mapping betwenn
eglconfig, egldisplay, eglsurface, eglcontext and the JOGL classes?

You can get the native handle of the display with EGLGraphicsDevice.getHandle(). You can call GLContext.getHandle() to get the native handle of the context. As far as I know, they are not abstracted in separated classes, maybe Sven can confirm.

On 02/21/2012 03:29 PM, seahorse [via jogamp] wrote:
>
>
> ok thanks for the response
>
> correct me if i am wrong but
> I am assuming JOGL has its EGL interface seperated out into seperate classes
> which is unrelated to the opengl classes.

EGL, GLX, WGL, .. and OpenGL are 'unrelated' yes.


> And I am assuming these seperate classes for SWT would be
> GLCanvas, GLCapabilites (set's EGL configs independent of GL)
> GLWindow(set's up EGL Surface independent of GL)

EGL surface is a detail of the jogamp.opengl.egl.EGLDrawable
and manages the special native-handle versus EGL-handle
like eglDisplay and eglSurface.

Some platforms have a 1:1 mapping (Android, ..)
where we use a native egl configuration in the NativeWindow.
Other platforms, eg. w/ X11/GLX or WGL, will map
their native handle to egl.

GLX, WGL, .. use a straight 1:1 mapping of the
drawable/surface handle.

> and the swap buffers call - Swapbuffers
> and for eglcontext?

EGLContext is a specialization of GLContext,
so is X11GLXContext, etc ..

>
> Is there a strict one to one mapping betwenn
> eglconfig, egldisplay, eglsurface, eglcontext and the JOGL classes?

These details are hidden within the egl package, see above.

In the end, a GLContext instance will have it's unique
handle, whether it's GLES or desktop GL.
The OpenGL function wrapping don't really care, as long the association
is properly and the function exist. Our framework takes care
of the proper mapping
  NativeWindow -> EGL/GLX/WGL -> GLProfile/GLContext -> ..

Hope this helps a bit.

For your simple 'reuse' of the GL context in native code,
you would just need to either:
  - call a native 'draw' method from java within:
      makeCurrent();
      try {
        myNativeDraw();
      } finally {
        releaseContext();
      }
    this is recommended!
    Here your native application doesn't need to worry about
    whether you use EGL, GLX, ..
    and you have also some sanity regarding context management.

  - Native management (won't work well w/ AWT):
    - Java: Lock the surface/gl-drawable
    - Java: Pass the gl-context and the gl-drawable-handle
            to your native code,
            w/o having the context current.
    - Native: do your stuff in native code, knowing which binding you use
      EGL, GLX, ..
    - Java: unlock surface

~Sven