We don’t have an OpenAL implementation in yet, if you’re talking about the Fasttracker file. If it’s some sort of graphics file, you can certainly implement it yourself once issue #38 and #35 is finished!
https://github.com/team-jgloom/jgloom/issues/35
https://github.com/team-jgloom/jgloom/issues/38
… You’re serious …
Hydroque can you do something other than turning every thread into something about you/derailing? Thanks.
@Ecumene, clever idea! Would be very handy.
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.
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 )
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 )
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).
The site is finished! (Except for a little animation I had planned for the bottom) The wiki was made with Jekyll, and so was the homepage.
Here’s the two themes I used:
Perhaps take a look at assimp / jassimp or consider incorporating it:
assimp
jassimp
Crazy! 40 formats supported, but no XM!
Edit: Oh yeah… Check out glTF as a prime format to support!
Why not looking at elect86’s pure Java port of assimp? It’s rudimentary now but if you encouraged him, maybe we would support much more formats 
Seriously, assimp is very good but I think that it’s totally doable in pure Java without creating another binding, look at existing engines supporting tons of formats, especially JMonkeyEngine 2 (MD2, ASE, 3DS, …), LibGDX, Xith3D (X3D, …) Unlicense Lib (3DS, Blender, BVH, Collada, FBX, LWO, Maya, MQO, MS3D, OBJ, OFF, PLY, STL, TDCG, X, MD2, MD3, MD5, MDL, VTF, VTX, VVD, PMD, PMX, VMD, VPD, UNITY3D, XNA, …) and JogAmp’s Ardor3D Continuation (Collada + OBJ + STL + MD3 + MD2 available right now, PLY available soon).
It seems to be very trivial to support.
Wow! Mind blown, that sounds awesome. I’ve never heard of ASSIMP, but we can certainly implement it!
Here’s a quick summary of how JGLOOm works for anyone who wants to contribute to the ASSIMP implementation:
WebGL4J, JOGL, and LWJGL are similar but have very simple differences. The idea is that we can write model and image loaders once, then have interfaces containing generic OpenGL functions point to real library calls. This means you can write file loaders once, and point their methods to wherever you want.
Here’s a package full of standard OpenGL methods for every object
Here’s a package full of standard OpenGL objects represented as interfaces
Here’s a package full of input / output resources (models are not finished and are badly made)
Here’s what JGLOOm would look like ported to LWJGL (WebGL and JOGL would be similar)
There’s a debate on the github now about which we should use (Pure Java, or the Java native binding)
https://github.com/team-jgloom/jgloom/issues/65
I just gave a look at your code, and I can offer myself to port it to WebGL4J. But there is a problem in jgloom-io that you are reading from InputStream and others which aren’t available in GWT. You’re also using ImageIO and BufferedImage classes? Other than that, this is great work.
Thanks! We’d love your help. Here’s some pointers:
Currently the image decoders read from an interface called [icode]Resource[/icode], we can easily make a new [icode]GWTResource[/icode] that could be anything you’d like, and the input stream could return null. This would pair with an [icode]GWTImageDecoder[/icode].
gouessej mentioned we are using AWT classes in the core library, and I am rightfully ashamed of myself. I’m working on making a new class that contains the basic data for uploading to a texture, this way we can abstract out all that nasty AWT stuff.
I’ll take a look into this for a few days (had training programme in college, so I can’t immediately work on this). And here are some things to keep in mind when working with GWT, and IO in specific.
[] There is no synchronous IO. IO should happen in form of XmlHttpRequests and we should use callbacks to do the result.
[] GWT has no support for threading, and waiting on the main thread will cause the browser to become unresponsive.
[] GWT doesn’t support reflection because it is a source-to-source translator.
[] There are only a limited number of classes emulated from the JRE, no NIO classes are available.
These are the things to keep in mind, and I think you are violating all these right now. Even though you get the data of the files through XHR, you can’t directly get the pixel data out of it. The only way to load images is to inject a IMG tag to the browser and set it to not visible, and once it’s loaded, you have to pass it directly to WebGL.
We can of course work-around the NIO classes by implementing a GWT support library with super source. Hope we can deal with these.
Ecumene, your third link is broken.
Sorry for the dummy question but what is your target? Which developers should use your library?
Actually, you’ll need at least a math library and you’ll need to provide something to manage the hierarchies, this is already implemented in numerous typical scenegraph APIs, middle-level and high-level frameworks and toolkits. Who would choose your library rather than LibGDX 3D API, JMonkeyEngine 3, Xith3D, Java3D, Unlicense Lib, JogAmp’s Ardor3D Continuation, …? Moreover, lots of those APIs focus on a few file formats (Blender for JMonkeyEngine 3, Collada for the legacy Ardor3D, FBX for LibGDX) because it’s better to support fewer formats very well than lots of format badly and there are numerous tools to convert 3D models. Some formats are better for long time storage and interchange but bad for use at runtime in a game, some formats are only good to be used with a particular editor and shouldn’t be used for interchange or in games. If you support all 3D file formats, you’ll end up with an API as complicated as those already available now, is it your aim?
Finally, I advise you to take some time to wisely choose a solution to support WebGL. GWT isn’t the only available option. Bck2Brwsr doesn’t have a WebGL binding yet but it supports the 2D canvas, it supports a larger subset of the standard JavaSE API than GWT and it’s faster (3 to 10 times slower than Hotspot). TeaVM supports WebGL.
Cough take a good look at assimp; oops already mentioned this… :
Khronos Showcases Significant glTF Momentum for Efficient Transmission of 3D Scenes and Models
Oops. Already mentioned that too… :persecutioncomplex: glTF is built for WebGL in mind and then some!
On glTF (don’t just take my word):
“The world has long needed an efficient, usable standard for 3D scenes that sits at the level of common image, audio, video, and text formats. Not an authoring format, or necessarily a format you would use for a hyper optimized platform specific application, but something at home on the internet, capable of being directly created and consumed by many different applications,” said John Carmack, CTO of Oculus.
My take is first and foremost provide a knock out glTF implementation 100% and adopt / support any translation efforts (FBX-glTF / FBX2glTF whitepaper / Collada2glTF) that are available. Don’t try to solve the all formats issue from scratch. If that really is an itch fully support assimp as a side show, but otherwise create the best glTF importer you can and you’ll be ahead of the game. Take cues from the partial assimp glTF import / exporter and examine the major javascript 3D frameworks that have adopted the format (three.js / babylon.js) and consider carefully a Java based format / essential rendering routines if not assimp derived.
Heck I’m tempted to take off a week from what I’m working on now and knock out a solid solution (err, of course based on TyphonRT… ;P… sigh… open sourcing plenty of things but not this:()…
LibGDX, JMonkeyEngine, and all the others are mainly game-engines, there’s plenty of use for high-preformance java graphics outside of games (computer simulation is what I made it for, but it can also be used in, for example, data-visualization) JGLOOm is fairly lightweight compaired to the other graphics solutions.
There’s good reasons to choose JOGL over LWJGL in some cases, and WebGL over LWJGL (of course). There should be an easy and similar-code-wise method for loading models for them
Good point, we’ll use jAssimp’s model importing standard, convert it to pure java (no NIO) and support a few of the masses choosing.
My thoughts on which formats, with good reason I’ll add more:
Zach and I are carefully working out the kinks over the phone, GWT is a very sensitive toolkit. We have a solution (somewhat) to every problem that may persist, allowing users to be able to decode any format similar to how you would in the LWJGL/JOGL ports. There will be options to support TeaVM, Bck2Brwsr, as well as GWT. The jgloom-core module will have to have as little code as possible, just simple stuff to decode file formats.
Yo, you can talk the talk… But can you walk the walk?
It’s just JSON, it’s very easy to serialize to java objects. As long as JSON serializer works in GWT, I’m happy. I can add you as a contributer, when we finish the jAssimp - GWT friendly we can get to work. (If your tempted :persecutioncomplex:)
While supporting a few file formats very well, there is only so much you CAN support. Meaning if you handle everything like its supposed to 100% of the time, or you are happy, don’t be afraid of starting work on something else if you so wish
[s]Update on GLTF, GWT can’t support it. I’m calling it now!
Unfortunately it points to binary buffers for mesh information,
Unless we modify the format to read from a plain text version of the meshes as simple (xyz,uv…) stuff, GLTF format won’t work. Thanks for the recommendation though, Catharsis!
EDIT:
Update on FBX, GWT can’t support it either.
Being a binary format, Javascript doesn’t have any way to load it. Leaving MD5 files as the only candidate for skeletal animations, unless someone else has anouther plain-text animated-3d-model solution [/s]
I just found an FBX loader in javascript as well as documentation for using glTF with WebGL. Herp derp:
http://threejs.org/examples/webgl_loader_fbx.html
