Java wrapping of OpenGL objects

Engines, Libraries and Tools
#1

I’m working on a library called JOOGL that allows manipulation of OpenGL objects as java objects. The idea is that there’s plenty of stuff you can do with OpenGL but if you want to get it done fast you have to use a large game-engine such as LibGDX. This library packages OpenGL objects into Java objects then provides methods to manipulate them, while not trying to achieve a synchronized state for each object on the Java side, but instead call back to the OpenGL library for data.

All of this is pseudo code, I haven’t touched this part of the library yet
If you have any corrections or inquiries just reply to this thread and I’ll think about it before I implement any features.

I had some ideas for the design and that’s what this thread is for:
There’s two sides to the library, JOOGL and OpenGL (or Java + OpenGL). Each OpenGL object has a Java interface:
[icode]buffer -> GLBuffer -> int getBuffer()[/icode]
[icode]texture -> GLTexture -> int getTexture()[/icode]
[icode]framebuffer -> GLFrameBuffer -> int getFrameBuffer()[/icode]

Binding and getting metadata for each OpenGL object on the Java side requires OpenGL calls, these are found in the metadata classes:

GLBuffers.getParameter(...)
GLFrameBuffers.setParameter(...)
GLTextures.activateUnit(...)

Then on the higher level side you have utilities for making Java objects that are then uploaded to the OpenGL side:

float[] vertexBuffer = new float[]{...}
GLFloatBuffer myObject = new GLFloatBuffer();
myObject.bind(GL15.GL_ARRAY_BUFFER);
// Looks back to see if it was bound already and uses that binding (GL_ARRAY_BINDING)
myObject.upload(vertexBuffer); 
...
// Draw using OpenGL 3.0 or 1.0 methods

This way anyone can easily load vertex buffers from 3D model files convert them to OpenGL buffers. Since the buffers are decoupled from the drawing method, you can use any drawing method you’d like (OGL 4, 3, 2) and sill support interleaving and objects with different strides.

I’m still working out the logistics of this, but my main issue with OpenGL right now is that there’s no easy platform for loading file formats for Java or when there are they conflict with the version I want to use / need to use for a specific system. I want a way I can just change an enumerator in code and have it automatically change the draw calls to a different method.

#2

This isn’t so different to just using LWJGL not JOGL (Your library name is too similar to JOGL as well). What benefits do you see over these 2 api’s?

#3

This isn’t an API, it’s more of an an extension of LWJGL. There’s libraries like this for C++ (like OOGL https://github.com/Overv/OOGL), but they have the same philosophies:
OpenGL is somewhat object oriented so we can make OO wrappers for the objects
Using our objects we can check for version support and have version-dynamic code

Then on a higher level we can make powerful loaders and constructors for the OpenGL objects, while still staying non-version agnostic.

#4

Please choose another name to avoid any confusion with JOGL.

Why not making games instead of making yet another tool?

#5

Because I don’t want to make games, computer simulation is my thing now :wink:

And the name is a play on OOGL https://github.com/Overv/OOGL the C++ one.

#6

I have to agree with gouessej here, the name can be very easily mistaken for JOGL. Play on a C++ lib or not, it can VERY easily confuse people (I thought your lib was for JOGL until I read the “extension for LWJGL” comment)

#7

It’s changed to JGLOOm (Java openGL: Object Oriented) now.
https://github.com/team-jgloom/jgloom

EDIT: The readme isn’t changed yet but it will when we merge feat/globjects