JGLOOm - Loading Every File Format for Every OpenGL Lib*

Engines, Libraries and Tools
#1

https://camo.githubusercontent.com/c31d4c38b0093c8f2627df4a76d4dd9c93d11cb7/68747470733a2f2f692e696d67736166652e6f72672f666134386161312e706e67

JGLOOm stands for Java openGL: Object Oriented (man!) it is Java library that wraps the functionality of the OpenGL API in a more object-oriented package. It puts OpenGL objects into Java interfaces, and their functions into static factories / container utils, allowing for code to be reactive to the user’s OpenGL version/platform dependency. It also provides users higher-level utilities like tracker objects that follow OpenGL values (like a texture parameter) around, reducing API calls.

Repository for loading file formats into those objects (no work has been done here yet)
https://github.com/team-jgloom/jgloom

Currently the library is in pre-production and we’re working on the standard for it. Here’s some stuff we have done though:

GLBuffers - Interface and LWJGL Containers
GLTextures - Interface and LWJGL Containers
GLFrameBuffers - Interface and LWJGL Containers
GLRenderBuffers - Interface and LWJGL Containers
GLSLShaders - Interface and LWJGL Containers
GLSLPrograms - Interface and LWJGL Containers

LWJGL Specific:
GLFWWindows - Interface and LWJGL Containers
GLFWMonitors - Interface and LWJGL Containers

Here’s how an object looks in our library

public interface GLBuffer {
    /** @return The identifier for the buffer object */
    int getBuffer();
}

The focus of this library was not just the higher-level manipulation of OpenGL objects, but also loading popular file formats such as these:
Image formats

  • JPEG
  • PNG
  • TIFF
  • GIF
  • BMP

Model formats (Planned)

  • MD5 - Animations and all
  • OBJ
  • FBX
  • Collada - We intend to use JCollada
  • Blend - In the very far future, as a tech demo (it would be very hard)

Behold the power of the higher level!

Lambdas:

public GLBuffer getMyBuffer(){
    int buffer = GL15.glGenBuffers(); 
    return () -> buffer;
}

Texture Loading into WebGL, JOGL, and LWJGL all at once!

// GLFTextureImage2D is a group of functions that represent an OpenGL texture that supports Image2D.
// It's class extends from GLFTexture, with defines basic functions like bind and delete
// Containers implement these functions as a sign of what their library supports (some libraries might not support GLFTextureImage3D for example)
TextureLoader.load(GLFTextureImage2D, InputStream)



// LWJGL's textures, as well as WebGL, JOGL and everything else supports Image2D, so their supported in their containers:
GLTextureContainer lwjglTexture = new GLTextureContainer(LWJGLTextures.createTexture())
JGLTextureContainer joglTexture = new JGLTextureContainer(JOGLTextures.createTexture())
WGLTextureContainer webTexture = new WGLTextureContainer(WGLTextures.createTexture())



TextureLoader.load(lwjglTexture, new FileInputStream(...));
TextureLoader.load(joglTexture, new FileInputStream(...));
TextureLoader.load(lwebTexture, new FileInputStream(...));

What we’re working on now is just that but with 3D models :persecutioncomplex:

More examples to come.

#2

Some information about helping with the project:

If you’re interested and have some good insight on features, create an issue on either the io or main repository or simply make a pull request! If you’re interested in making pull requests like that more frequent, email me to be added to the github team: mitchell.hynes@ecumene.xyz

#3

A framework or a wrapper?

#4

Those are some very arbitrary definitions, but I’m guessing a wrapper and framework?

It depends. In the main repository (jgloom) you’ve got OpenGL objects wrapped into interfaces and containers for manipulating them, then in the other (jgloom-io) it’s more like a framework for loading file formats and selecting draw call methods, stuff like that (which is not currently being worked on). This thread is mainly a placeholder till we can get our Travis-CI server setup and github wiki, seeing if anyone’s interested.

#5

My concern here is you are wrapping and acting like it’s a framework. I think the goal should be a framework directly editing the wrapper that is lwjgl.

#6

The issue here is that OpenGL was made for C, all their objects are pointed with integers. I wanted to “wrap” them with interfaces so they become more object oriented and you can manipulate them easier, as well as extend from their type. Effectively creating an open-standard that people can use although if they want features like tracking a texture parameter they can for example code that into a “manipulator” or container. For ease of use I also bundle my own example containers into the library accommodating the interfaces, it’s even in it’s own package [icode]jgloom.common.*[/icode]

If anything it’s more of a “wrapper”. But has framework capabilities in a separate package. So they can be both.

#7

I see, but this would be perfect to include bundled with lwjgl ie extending it.

#8

It makes more sense to have it as a higher-level library, LWJGL is supposed to encompass bindings (not wrappings) to OpenGL, OpenCL, and OpenAL.

#9

What is the sound of one hand clapping?

#10

snap

#11

Update!

I wrote an issue on the github page explaining a feature on how JGLOOm can load file formats for WebGL, LWJGL, JOGL, and many other libraries seamlessly (write once run anywhere).
https://github.com/team-jgloom/jgloom/issues/34

It will be in JGLOOm 1.0 and after it, OpenGL query object support will follow, then the backbone for OBJ loading in JGLOOm 1.3.

#12

Another update!

We’ve finished implementing the GL function groups into interfaces, but it can be greatly improved to help set a better standard for file loading in Java OpenGL. We currently support all the primary image formats including TIFF, and we plan to support all the popular 3D model formats once me and zach decide on a good standard :persecutioncomplex:

1.0 is “technically” finished now, but the standard can change if we see fit and we’re moving onto 1.1 which include these features:

  • Model formats MD5, OBJ, Collada (partially and through JCollada), FBX, and Blend (also partially, and probably in a later version too)
  • JOGL port

We also plan to port to WebGL4J, LWJGL 2, and other libraries.

#13

Pretty interesting project. Good luck with it!

#14

I see you support ImageIO for the image decoding. This is a project that creates its own plugins for the ImageIO repository

They write the own versions of the standard supported image file formats and they extend to many other formats. I would give this a thumbs up for people to use, the plug in’s are much better than the basic ones you get in Java (some of which have had no development for a very long time)

#15

Thanks!

I’ll make an issue for adding it, we may just have a separate class specifically for loading TwelveMonkey’s ImageInputStreams called [icode]TMTextureLoader#loadTexuture(GLFTextureImage2D, ImageInputStream)[/icode]

EDIT: Here’s the issue if anyone want’s to track it’s progress: https://github.com/team-jgloom/jgloom/issues/49

#16

Thanks! It’s still in it’s early development cycle and we’re progressing very very slowly. I’m updating the JGO thread to contain the new info about how it will load file formats for every Java OpenGL library out there, and do it well.

I’d love some fake Github internet points if you like the project :persecutioncomplex:

#17

Bam! Thread is updated.

#18

Why is there no support for XM files?

#19

How did you think that it is popular formats?

#20

I think you know the answer to that question, even if you don’t want to admit it.