Ecumene
|
 |
«
Posted
2016-05-29 15:48:42 » |
|
 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/jgloomCurrently the library is in pre-production and we're working on the standard for it. Here's some stuff we have done though: 1 2 3 4 5 6 7 8 9 10
| 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 1 2 3 4
| public interface GLBuffer { 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 Model formats (Planned) - MD5 - Animations and all
- OBJ
- FBX
- Collada - We intend to use [JCollada](http://javacollada.sourceforge.net/)
- Blend - In the very far future, as a tech demo (it would be very hard)
Behold the power of the higher level!Lambdas: 1 2 3 4
| public GLBuffer getMyBuffer(){ int buffer = GL15.glGenBuffers(); return () -> buffer; } |
Texture Loading into WebGL, JOGL, and LWJGL all at once! 1 2 3 4
|
TextureLoader.load(GLFTextureImage2D, InputStream)
|
1 2 3 4
| GLTextureContainer lwjglTexture = new GLTextureContainer(LWJGLTextures.createTexture()) JGLTextureContainer joglTexture = new JGLTextureContainer(JOGLTextures.createTexture()) WGLTextureContainer webTexture = new WGLTextureContainer(WGLTextures.createTexture())
|
1 2 3
| 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 More examples to come.
|
|
|
|
Ecumene
|
 |
«
Reply #1 - Posted
2016-05-29 15:55:41 » |
|
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
|
|
|
|
Hydroque
|
 |
«
Reply #2 - Posted
2016-05-31 02:39:49 » |
|
A framework or a wrapper?
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Ecumene
|
 |
«
Reply #3 - Posted
2016-05-31 18:11:01 » |
|
A framework or a wrapper?
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.
|
|
|
|
Hydroque
|
 |
«
Reply #4 - Posted
2016-05-31 20:03:10 » |
|
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.
|
|
|
|
Ecumene
|
 |
«
Reply #5 - Posted
2016-05-31 20:27:48 » |
|
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.
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 If anything it's more of a "wrapper". But has framework capabilities in a separate package. So they can be both.
|
|
|
|
Hydroque
|
 |
«
Reply #6 - Posted
2016-05-31 22:26:51 » |
|
I see, but this would be perfect to include bundled with lwjgl ie extending it.
|
|
|
|
Ecumene
|
 |
«
Reply #7 - Posted
2016-05-31 22:55:00 » |
|
I see, but this would be perfect to include bundled with lwjgl ie extending it.
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.
|
|
|
|
ags1
|
 |
«
Reply #8 - Posted
2016-05-31 23:42:07 » |
|
A framework or a wrapper?
What is the sound of one hand clapping?
|
|
|
|
basil_
|
 |
«
Reply #9 - Posted
2016-06-01 14:19:52 » |
|
snap
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Ecumene
|
 |
«
Reply #10 - Posted
2016-06-16 19:40:55 » |
|
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/34It 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.
|
|
|
|
Ecumene
|
 |
«
Reply #11 - Posted
2016-07-08 23:52:07 » |
|
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  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.
|
|
|
|
orange451
|
 |
«
Reply #12 - Posted
2016-07-14 06:01:50 » |
|
Pretty interesting project. Good luck with it!
|
|
|
|
ziozio
|
 |
«
Reply #13 - Posted
2016-07-15 03:57:23 » |
|
I see you support ImageIO for the image decoding. This is a project that creates its own plugins for the ImageIO repository https://github.com/haraldk/TwelveMonkeysThey 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)
|
|
|
|
Ecumene
|
 |
«
Reply #14 - Posted
2016-07-15 04:17:08 » |
|
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)
Thanks! I'll make an issue for adding it, we may just have a separate class specifically for loading TwelveMonkey's ImageInputStreams called TMTextureLoader#loadTexuture(GLFTextureImage2D, ImageInputStream) |
EDIT: Here's the issue if anyone want's to track it's progress: https://github.com/team-jgloom/jgloom/issues/49
|
|
|
|
Ecumene
|
 |
«
Reply #15 - Posted
2016-07-15 04:27:58 » |
|
Pretty interesting project. Good luck with it!
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 
|
|
|
|
Ecumene
|
 |
«
Reply #16 - Posted
2016-07-15 04:36:04 » |
|
Bam! Thread is updated.
|
|
|
|
Hydroque
|
 |
«
Reply #17 - Posted
2016-07-16 03:57:49 » |
|
Why is there no support for XM files?
|
|
|
|
SHC
|
 |
«
Reply #18 - Posted
2016-07-16 06:20:09 » |
|
Why is there no support for XM files?
How did you think that it is popular formats?
|
|
|
|
HeroesGraveDev
|
 |
«
Reply #19 - Posted
2016-07-17 05:53:20 » |
|
Why is there no support for XM files?
I think you know the answer to that question, even if you don't want to admit it.
|
|
|
|
|
Hydroque
|
 |
«
Reply #21 - Posted
2016-07-18 07:08:27 » |
|
... You're serious ...
|
|
|
|
Opiop
|
 |
«
Reply #22 - Posted
2016-07-18 12:44:15 » |
|
Hydroque can you do something other than turning every thread into something about you/derailing? Thanks.
@Ecumene, clever idea! Would be very handy.
|
|
|
|
Ecumene
|
 |
«
Reply #23 - Posted
2016-08-12 03:54:12 » |
|
JGLOOm has an official webpage now, if anyone wants to contribute we're looking for good documentation writers! You'll have your name on the home-page. http://jgloom.org/EDIT: We also need help in porting the (non-existant...) loaders to Vulkan, this wouldn't be too hard to accomplish, as we only have to write the wrappers for LWJGL. ( Unless someone knows where I can find some other java library supporting vulkan )
|
|
|
|
gouessej
|
 |
«
Reply #24 - Posted
2016-08-12 13:56:57 » |
|
I see you support ImageIO for the image decoding. This is a project that creates its own plugins for the ImageIO repository https://github.com/haraldk/TwelveMonkeysThey 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) I confirm that TwelveMonkeys is quite reliable and efficient, some plugins support some image formats not supported by ImageIO (ICO, ...). However, it means that JGLOOm has no chance to load images where Swing and AWT aren't available unlike JOGL 2 which contains its own decoder for several image formats including PNG.
|
|
|
|
Ecumene
|
 |
«
Reply #25 - Posted
2016-08-12 20:09:43 » |
|
I confirm that TwelveMonkeys is quite reliable and efficient, some plugins support some image formats not supported by ImageIO (ICO, ...). However, it means that JGLOOm has no chance to load images where Swing and AWT aren't available unlike JOGL 2 which contains its own decoder for several image formats including PNG.
Good point! I had plans to make the default "TMImageDecoder" (Previously ImageDecoder) a singleton, and have all TextureLoader contain a 'ImageDecoder' interface that responds to InputStreams (Resource Interface) with FloatBuffers. They all select the TMImageDecoder as the default. I'm not sure what this pattern is called, but it's a sort of hybrid between a singleton and a regular object, there's still one static instance but other instances can be made... ( They could both be singletons, Idk )
|
|
|
|
Ecumene
|
 |
«
Reply #26 - Posted
2016-08-12 20:38:14 » |
|
|
|
|
|
gouessej
|
 |
«
Reply #27 - Posted
2016-08-12 22:52:57 » |
|
You're welcome. Your utility to create NIO buffers creates only direct NIO buffers but you provide no mean of releasing their native memory. I advise you to read my answer on SO. My very last suggestion under a permissive license would allow you to solve this problem (I don't suggest you to use my source code as the license I use is incompatible with yours).
|
|
|
|
|
Catharsis
|
 |
«
Reply #29 - Posted
2016-08-15 03:52:51 » |
|
Perhaps take a look at assimp / jassimp or consider incorporating it: assimpjassimpCrazy! 40 formats supported, but no XM! Edit: Oh yeah... Check out glTF as a prime format to support!
|
|
|
|
|