Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (798)
Games in Android Showcase (234)
games submitted by our members
Games in WIP (865)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  JGLOOm - Loading Every File Format for Every OpenGL Lib*  (Read 50822 times)
0 Members and 1 Guest are viewing this topic.
Offline gouessej
« Reply #30 - Posted 2016-08-15 09:04:28 »

Perhaps take a look at assimp / jassimp or consider incorporating it:
assimp
jassimp
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 Wink

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).

Edit: Oh yeah... Check out glTF as a prime format to support!
It seems to be very trivial to support.

Julien Gouesse | Personal blog | Website | Jogamp
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #31 - Posted 2016-08-15 16:30:13 »

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

Offline SHC
« Reply #32 - Posted 2016-08-15 17:03:40 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #33 - Posted 2016-08-15 17:34:20 »

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?

Thanks! We'd love your help. Here's some pointers:
Currently the image decoders read from an interface called
Resource
, we can easily make a new
GWTResource
that could be anything you'd like, and the input stream could return null. This would pair with an
GWTImageDecoder
.

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.

Offline SHC
« Reply #34 - Posted 2016-08-15 18:29:43 »

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.

Offline gouessej
« Reply #35 - Posted 2016-08-17 00:35:28 »

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.

Julien Gouesse | Personal blog | Website | Jogamp
Offline Catharsis

JGO Ninja


Medals: 76
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #36 - Posted 2016-08-17 02:35:46 »

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

Cough take a good look at assimp; oops already mentioned this..  Roll Eyes

because it's better to support fewer formats very well than lots of format badly and there are numerous tools to convert 3D models.
Finally, I advise you to take some time to wisely choose a solution to support WebGL.

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:()..

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #37 - Posted 2016-08-17 03:38:47 »

Sorry for the dummy question but what is your target? Which developers should use your library?
Who would choose your library rather than LibGDX 3D API, JMonkeyEngine 3, Xith3D, Java3D, Unlicense Lib, JogAmp's Ardor3D Continuation, ...?

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

it's better to support fewer formats very well than lots of format badly and there are numerous tools to convert 3D models.

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:
- OBJ
- FBX
- MD5
- FBX
- glTF

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.

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.

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:()..

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)

Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Reply #38 - Posted 2016-08-17 03:48:45 »

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 Smiley

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #39 - Posted 2016-08-17 04:09:15 »

Update on GLTF, GWT can't support it. I'm calling it now!

Unfortunately it points to binary buffers for mesh information,
1. GWT is a source-to-source compiler meaning we can't use native code, or binary formats (unless you load it in booleans or something)
2. WebGL4J doesn't have any methods to upload native-style buffers anyways, so it's a bust.

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


I just found an FBX loader in javascript as well as documentation for using glTF with WebGL. Herp derp:
https://www.khronos.org/gltf
http://threejs.org/examples/webgl_loader_fbx.html

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #40 - Posted 2016-08-17 12:55:27 »

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.
Half of the scenegraph APIs I quoted aren't mainly for games. If the main "advantage" of your library is its light weight, you'll aim a tiny niche containing those who need more than just a set of bindings for OpenGL & OpenGL ES APIs and those who need less than a middle-level framework like LibGDX. This niche is already occupied by jReality and jzy3D. You talk about computer simulation and data visualization but I don't see numerous formats used in scientific visualization in your lists and unfortunately, as time goes by, there are fewer of them supported in major 3D editors like Blender (especially since its version 2.50). PLY and STL models can be converted into OBJ, it shouldn't be a problem. I see neither U3D nor Collada in your list.

Julien Gouesse | Personal blog | Website | Jogamp
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #41 - Posted 2016-08-17 15:29:28 »

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.
You talk about computer simulation and data visualization but I don't see numerous formats used in scientific visualization in your lists and unfortunately

What formats are used?

By computer simulation, I meant primarily on the web. Hence the webGL

Offline SHC
« Reply #42 - Posted 2016-08-17 16:06:07 »

GWT and JS both have the support for reading binary files too. You can create an XHR to a file, set it's type to ArrayBuffer and receive an array buffer, which is like a container for binary data. You can create a DataView on top of it which behaves like a DirectByteBuffer. For example, here is a GwtDirectBuffer class that I wrote for the GWT backend of SilenceEngine.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
public void readBinaryFile(FilePath file, UniCallback<DirectBuffer> onComplete)
{
    // Create a XMLHttpRequest to load the file into a direct buffer
    XMLHttpRequest request = XMLHttpRequest.create();
    request.open("GET", file.getAbsolutePath());

    // Set to read as ArrayBuffer and attach a handler
    request.setResponseType(XMLHttpRequest.ResponseType.ArrayBuffer);
    request.setOnReadyStateChange(xhr -> {
        if (request.getReadyState() == XMLHttpRequest.DONE)
            // Invoke the onComplete handler
            onComplete.invoke(new GwtDirectBuffer(request.getResponseArrayBuffer()));
    });

    // Send the request
    request.send();
}

And now I have this method to read the file as a binary file. Note that this is callback based because of JavaScript's single threaded nature. Once done, the callback is invoked, and then you can simply read the bytes from the buffer as you wish.


Offline Catharsis

JGO Ninja


Medals: 76
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #43 - Posted 2016-08-17 16:31:55 »

convert it to pure java (no NIO)
Shocked Huh

It's just JSON, it's very easy to serialize to java objects.

JSON description -> binary blobs + assets -> NIO -> profit...
                        |
                        +-> shaders -> profit...
                        |
                        + scenegraph -> pure java / component architecture preferably -> profit...                      
 
Yo, you can talk the talk... But can you walk the walk?

Hey man, I can guide the path, but shine you must..  Tongue  

Currently walking the walk plenty busy creating fundamental tools; that one should be over 3k daily downloads by end of Sept.. rounding out the arsenal so to speak... more to come...  

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #44 - Posted 2016-08-17 19:22:08 »


NIO Buffers (and all the other natives), to my understanding, don't work with GWT, right?

binary blobs + assets -> NIO -> profit...
That's the part that scared me, but SHC showed you can still use binary formats in GWT!

Hey man, I can guide the path, but shine you must..  Tongue  
Currently walking the walk plenty busy creating fundamental tools; that one should be over 3k daily downloads by end of Sept.. rounding out the arsenal so to speak... more to come... 

Typhoon looks very interesting, I knew you had your Java app but you seem to exploded in crazy works. Nice job!

Thanks for the tips on importing glTF, hopefully that'll be the first format we support.

Offline gouessej
« Reply #45 - Posted 2016-08-18 00:13:25 »

What formats are used?
PLY, OFF, STL, Mathematica Graphics 3D, VTK, ...

Actually, if you separated the geometry storages used during the parsing (pure Java, no NIO at this stage) from the creation of meshes and nodes containing the data for OpenGL (typically the NIO buffers) and if you chose a math library widely used by several engines (for example Vecmath, used as is in Java3D, a variant used in Xith3D, another variant used in JogAmp's Ardor3D Continuation), those engines could use your stuff, maybe with a Maven plugin to adapt the imports, and you could use most of their loaders. However, it's up to you and I understand that you prefer using jAssimp.

Julien Gouesse | Personal blog | Website | Jogamp
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #46 - Posted 2016-08-18 14:12:38 »

However, it's up to you and I understand that you prefer using jAssimp.

My plan was to have an AiSceneRenderer that simply renders a scene given an AiScene. Then we'd have different variations of LWJGLAiRenderer, WebGLGWTAiRenderer, and JOGLAiRenderer. Since there's no universal model class we can easily support lots of formats and loading libraries.

I'm concerned now about Vecmath libraries, as a lot of those libraries use a proprietary vecmath solution...

Offline SHC
« Reply #47 - Posted 2016-08-18 14:32:07 »

My plan was to have an AiSceneRenderer that simply renders a scene given an AiScene. Then we'd have different variations of LWJGLAiRenderer, WebGLGWTAiRenderer, and JOGLAiRenderer.

My advice is to create an interface with OpenGL functions that the renderer would need, and implement the renderer in the core. The interface with the opengl functions will be passed to the renderer from the backends.

Offline gouessej
« Reply #48 - Posted 2016-08-18 21:45:33 »

I'm concerned now about Vecmath libraries, as a lot of those libraries use a proprietary vecmath solution...
Proprietary? It's under GPL v2 with Classpath exception (i.e non viral):
https://github.com/gouessej/vecmath/blob/master/LICENSE.txt

What did you mean exactly?

Julien Gouesse | Personal blog | Website | Jogamp
Offline Catharsis

JGO Ninja


Medals: 76
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #49 - Posted 2016-08-18 21:47:38 »

That's the part that scared me, but SHC showed you can still use binary formats in GWT!

Yep ArrayBuffer / and whatever view matches for the copy.

Typhon looks very interesting, I knew you had your Java app but you seem to exploded in crazy works. Nice job!

TyphonRT has 13 years of crazy works behind it though just not open source for all to see; so as far as crazy works what's visible is the tip of the iceberg.. Wink I just want to get to something commercially launched that justifies any ROI before open sourcing TyphonRT. TyphonJS I'm open sourcing and that has been refreshing to get things out for folks to use, but haven't publicized anything yet about it. TyphonJS is also a test on building the infrastructure for the many-repo approach. Even a year ago that approach only is possible on Github financially speaking for open source repos (free). I believe ~6 months ago Github finally changed the pricing structure for unlimited private repos per org / user for a flat fee per user. Even then that doesn't fit the model I'm developing as I treat Github organizations as a "component category" hence if I want private repos across ~30 organizations for one user that is ~$210 a month; better than it used to be though. There is Gitlab (free private repos), but I'm going to evaluate that later. TyphonJS is spread over ~25 organizations currently each with repos specific to the category that the organization represents. Some tooling is available (how the listing on typhonjs.io is created), but I've got a few unpublished tools that given a regex and Github token for instance all repos of TyphonJS across all organizations can be cloned in bulk and WebStorm projects automatically created and npm / jspm install run in one batch (no need to manually install everything which would be crazy).. Eventually a GUI configuration tool for apps will allow appropriate selections for an end project to be created with referenced NPM / JSPM modules that create the appropriate project with all resources, etc... Lot's more, but I'll stop here though as this is a JGloom thread.. ;P

Thanks for the tips on importing glTF, hopefully that'll be the first format we support.

Also keep in mind the glTF binary extension

So the canary in the coal mine in all the discussion thus far is that what you are trying to pull off is complex. If you go down the traditional OO route you're going to be screwed if not more so than a generic OO entity system. Especially screwed if you ever want to support Vulkan efficiently.

The direction I recommend is a purely event driven path for model loading and rendering. There are no direct connections between subsystems. Just events that each subsystem responds to and posts further output events handled by the next system in the chain. This works for loading and rendering or whatever else JGloom does. Unfortunately there is no publicly available efficient / component oriented event bus for Java out there (yep, TyphonRT is based on this).

Let's assume a JGloom instance manages all models / scenes loaded. JGloom has an event bus internally used.

Promise modelID = jgloom.load(*a loaded gltf file*);

Let's assume "load" might introspect the type of file or data being loaded. A modelID is assigned, promise created and returned after posting two events on the internal JGloom event bus. The first, CREATE_MODEL, forwards on the model ID and promise which is received by a management system. The second, LOAD_GLTF, with the raw file data after introspection and associated model ID.

The GLTF parser receives the LOAD_GLTF message and then starts unpacking and finds out there are 5 things to load. First it fires an event on the event bus PARSING_GLTF with the model ID and how many assets are being loaded which is received by a collector system which creates the complete model instance / component manager (hopefully). The parser then fires off 5 events (let's say there is 1 texture, 2 shaders, 2 binary blobs), so the following is punted to the event bus with model ID and raw data from the glTF file: LOAD_GLTF_TEXTURE (x1), LOAD_GLTF_SHADER (x2), LOAD_GLTF_BINARY (x2). One or more separate loading systems receive these events and then create the proper resources for the GL or Vulkan or whatever environment being used. IE when you create a JGloom runtime for GWT you load GWT loader / renderer systems which for instance store binary data in ArrayBuffers or JOGL, LWJGL with NIO buffers, etc. Each of those loader systems create the proper assets / format and post with the model ID: LOADED_GLTF_TEXTURE (x1), LOADED_GLTF_SHADER (x2), LOADED_GLTF_BINARY (x2). The previously mentioned collector system receives these events and adds the loaded data to the model and once all assets are received given the asset count emits a LOADED_MODEL event with the model ID and model which is picked up by the management system tracking the initially returned promise replacing the promise placeholder with the actual managed model then completes / fulfills the promise.  I guess you could also get fancy and support reactive events (RxJava, etc.) or expose an external eventbus as well as promises.

The user can then retrieve the actual model from JGloom... Let's say jgloom.get(modelID).

Another great reason for this kind of architecture is that it's really easy to provide a JGloom implementation that entirely excludes any renderer and defers to the app to render or even a model creator system that loads assets into an existing engine structure if applicable such as JMonkeyEngine, etc. The latter of course if the engine defines a fine grain API to import assets / scenegraph nodes, etc.

This is still all a strawman architecture idea, but perhaps gives a different perspective. The renderer would a bit more complex... Considering batching, animation, culling, etc. etc. At a certain point the user needs to be in control of these aspects. The nice thing though is that a fully decoupled system could load a user provided system without the complexity of a complicated OO dependency hierarchy.

While not super deep on details check out Dan Baker's / Oxide Games talk on Vulkan and Ashes of Singularity engine.  Take note when he mentions that the renderer can be swapped out and the rest of the engine / architecture doesn't care.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline elect

JGO Knight


Medals: 69



« Reply #50 - Posted 2016-08-19 12:17:11 »

My plan was to have an AiSceneRenderer that simply renders a scene given an AiScene.

That's far above the task of a loading meshes library  Tongue
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #51 - Posted 2016-08-20 00:43:00 »

That's far above the task of a loading meshes library  Tongue

Ya, that's fair. We can probably just generate AIScenes to buffers compatible to each library only, and users can point that to vertex arrays however they'd like. That way it's not completely useless persecutioncomplex

Plus we don't have to deal with the whole OpenGL version debacle, that I complain too much about.

Offline elect

JGO Knight


Medals: 69



« Reply #52 - Posted 2016-08-20 09:07:39 »


Ya, that's fair. We can probably just generate AIScenes to buffers compatible to each library only, and users can point that to vertex arrays however they'd like. That way it's not completely useless persecutioncomplex

Plus we don't have to deal with the whole OpenGL version debacle, that I complain too much about.

Float (/double) for vertices/normals/uv and int (/short) for indices?
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #53 - Posted 2016-08-20 16:34:51 »

Float (/double) for vertices/normals/uv and int (/short) for indices?

Essentially, although it can probably change per model format (some formats may require higher percision, I donno)

Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #54 - Posted 2016-08-20 16:48:22 »

My advice is to create an interface with OpenGL functions that the renderer would need, and implement the renderer in the core. The interface with the opengl functions will be passed to the renderer from the backends.

Aha! Gotcha. Already a step ahead of you!

1. Objects are in their own little interfaces (
GLBuffer -> (int)
).
 - Each library has their own constructors for these objects, so we're getting pointers from the right libraries (LWJGLBuffers.createBuffer(), LWJGLFramebuffers.createFramebuffer(), ...)
2. Objects are manipulated by function interfaces:
 - GLF[Object] specifies basic uses of each object (bind, destroy ...) stuff that all libraries support
 - GLF[Function] specifies specialized functions (GLFTexImage3D, GLFBufferSubData) stuff that some libraries support (these extend from the GLF[Object])
3. Containers contain objects for that library, and implement the function interfaces that the library supports, making for very easy use of the object in core loaders
 - Check out AbstractGLBuffer (LWJGL) and GLBufferContainer (LWJGL)
4. Loaders in the core can manipulate objects from any library by using the function interface for that object.
 - Since the GLF[Function] extends GLF[Object], you can still do the basic functions of each object, as well specialized loaders
 - For example:
loadTexture(int target, GLFTextureImage2D texture, ... texture.texImage2D(...)

Offline Catharsis

JGO Ninja


Medals: 76
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #55 - Posted 2016-08-20 23:57:37 »

The direction I recommend is a purely event driven path for model loading and rendering. There are no direct connections between subsystems. Just events that each subsystem responds to and posts further output events handled by the next system in the chain.

So to continue the strawman architecture and why you must consider an asynchronous architecture (event driven / event bus) let's consider the full glTF spec. In my previous outline of what event control flow could look like I took liberties that the glTF file being parsed indeed contained all of the assets; data URIs as per the spec. Most model formats contain all of the assets to load. glTF is different though as any asset in the glTF file may just be an external URI reference relative to the glTF file being loaded that needs to be downloaded separately from the glTF file itself. This presents a direct example why an asynchronous architecture is needed.

Previously in my last reply I mentioned:
Let's assume "load" might introspect the type of file or data being loaded. A modelID is assigned, promise created and returned after posting two events on the internal JGloom event bus. The first, CREATE_MODEL, forwards on the model ID and promise which is received by a management system. The second, LOAD_GLTF, with the raw file data after introspection and associated model ID.

The glTF parser receives the LOAD_GLTF message and then starts unpacking and finds out there are 5 things to load. First it fires an event on the event bus PARSING_GLTF with the model ID and how many assets are being loaded which is received by a collector system which creates the complete model instance / component manager (hopefully). The parser then fires off 5 events (let's say there is 1 texture, 2 shaders, 2 binary blobs), so the following is punted to the event bus with model ID and raw data from the glTF file: LOAD_GLTF_TEXTURE (x1), LOAD_GLTF_SHADER (x2), LOAD_GLTF_BINARY (x2).

Well shoot let's say the glTF file is loaded from a remote URI and the file now includes external URI entries for one or more of the assets to load. The call to JGLoom might now look like:
1  
Promise modelID = jgloom.load('https://raw.githubusercontent.com/KhronosGroup/glTF/master/sampleModels/CesiumMilkTruck/glTF/CesiumMilkTruck.gltf')

https://github.com/KhronosGroup/glTF/tree/master/sampleModels/CesiumMilkTruck/glTF

This means `jgloom.load` detects the URI and determines it's some remote file to load. Let's say the JGloom load API has an internal implementation that takes the actual loaded file. Like before from the public API a modelID is assigned, promise created and returned. Then LOAD_EXTERNAL_URI is posted on the internal JGloom event bus, with the URI of the file to load the associated model ID to load and a separate promise which accepts the loaded file and invokes the internal load implementation that takes the actual file. The system that receives LOAD_EXTERNAL_URI makes the HTTP request and upon receipt of the file fulfills the loader promise. Now we are more or less back to the control flow initially described. The internal load implementation determines it's a glTF file and fires two events: CREATE_MODEL, LOAD_GLTF. As an aside what if the URI is a local "file://" URI. No problems as the external URI loader system accesses the file system and proceeds just like it would if it were a remote request.

The glTF parser receives the LOAD_GLTF message and then starts unpacking and finds out there are 5 things to load. First it fires an event on the event bus PARSING_GLTF with the model ID and how many assets are being loaded which is received by a collector system which creates the complete model instance / component manager (hopefully). However now all the assets are external URIs not locally available. Now the parser will create 5 promises which receive the file of the asset and like before subsequently punts individually to the event bus with model ID and raw data from the external file: LOAD_GLTF_TEXTURE (x1), LOAD_GLTF_SHADER (x2), LOAD_GLTF_BINARY (x2) So the parser then fires off 5 LOAD_EXTERNAL_URI events to the JGloom internal event bus. The system handling LOAD_EXTERNAL_URI resolves these promises and the control flow resumes as originally described collecting and completing the model loading process.

The event driven / event bus architecture perfectly handles these cases.

What if there is an error though. Let's say an external resource 404s. The system handling external requests resolves the file request promise with an error and message. The error handler of the request promise now posts an event to the internal event bus LOAD_MODEL_ERROR with the model ID and a descriptive message. The collector system receives this message and cleans up resources and removes tracking for the given model ID. The management system receives the message and resolves the modelID promise passed back to the user with an error and removes tracking for that modelID.

Consider up front the benefit of an asynchronous architecture. A traditional OO architecture especially with discrete listeners will fold and be hard to maintain / debug.

I looked around for Java promise libraries that work on Android and it seems like JDeferred might be a good choice.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #56 - Posted 2016-08-21 01:10:30 »

The event driven / event bus architecture perfectly handles these cases.
I looked around for Java promise libraries that work on Android and it seems like JDeferred might be a good choice.

Interesting, I should go about implementing an asynchronous architecture... I'm not very good at designing async machines, using an object before it *exists* doesn't excite me.
If anyone has some good reads on async, please PM me. I'm pretty dumbfounded when it comes to anything other than basic OO.

I'd love to look into it though, since we haven't started with the loading yet it should be a quick bid to get working!
Thanks for the help Catharsis!

Offline Catharsis

JGO Ninja


Medals: 76
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #57 - Posted 2016-08-21 07:30:49 »

Interesting, I should go about implementing an asynchronous architecture... I'm not very good at designing async machines, using an object before it *exists* doesn't excite me.
If anyone has some good reads on async, please PM me. I'm pretty dumbfounded when it comes to anything other than basic OO.

Java definitely has been late to the game for a good promise based solution. Java 8 introduces CompletableFuture. The only problem is that it is just introduced in Android API level 24 which precludes it really being usable per se. JDeferred seems like the best available external option presently. A promise is an object.

There are several OO event bus implementations around. GWT has one, Guava, there are many others. The last one might be a good candidate for an existing solution. Events are fully formed objects... Err of course I think all of them are flawed in respect to a component architecture.

When I mention component architecture essentially I mean a generic application of what has received attention in the Java sphere of things as an "Entity System"; Artemis, Ashley, etc. etc. (all flawed per se). At the heart of it the important design concern is implicit composition. The TyphonRT event bus implementation uses extensible enums as event categories. The all caps "event IDs" that I mention in the previous post like LOAD_GLTF, or CREATE_MODEL are extensible enums. With TyphonRT an event is still an object, but a component manager. You can attach any type of data to it dynamically and other systems register with the event bus under the extensible enum categories or catch alls. In this respect there are no specific event types like the traditional OO approach. An event is defined by the category / extensible enums it's posted under and there is just one type of event which has data implicitly attached.

You can still get away with traditional OO, but there will be a proliferation of concrete event types. If you get the design right up front it all can still work. Consider new extensions to glTF then you have to mutate the events passed through the system or introduce new ones.

I'm playing fast and loose in the conversation in general.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Ecumene

JGO Kernel


Medals: 200
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #58 - Posted 2016-08-21 12:09:46 »

That's awesome! I never considered event busses, I've always used proprietary listeners... I'll see if I can implement guava into the library.

Offline Catharsis

JGO Ninja


Medals: 76
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #59 - Posted 2016-08-21 18:32:07 »

That's awesome! I never considered event busses, I've always used proprietary listeners... I'll see if I can implement guava into the library.

Definitely consider not using traditional / old school listeners if sanity is to be maintained. Wink

**Opinionated** Absolutely avoid Guava at all costs and dubiously view and double check anything that has touched Google engineering hands. Despite reputation laziness abounds within Google engineering. JGloom is already going to be bloated beyond belief as far as API surface is concerned let alone internal implementation going down the traditional OO route. If you add external libraries as dependencies pick the smallest most efficient and purpose built ones for the task. I guess that is another thing that should be in mind now and not later and that is creating the smallest API surface and modularization of JGloom.

JDeferred and Green Robot eventbus seem like reasonable candidates from a cursory search. I haven't used either of these libraries, so evaluate them!.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Pages: 1 [2] 3
  ignore  |  Print  
 
 

 
Riven (81 views)
2019-09-04 15:33:17

hadezbladez (4336 views)
2018-11-16 13:46:03

hadezbladez (1547 views)
2018-11-16 13:41:33

hadezbladez (4462 views)
2018-11-16 13:35:35

hadezbladez (871 views)
2018-11-16 13:32:03

EgonOlsen (4152 views)
2018-06-10 19:43:48

EgonOlsen (4855 views)
2018-06-10 19:43:44

EgonOlsen (2803 views)
2018-06-10 19:43:20

DesertCoockie (3707 views)
2018-05-13 18:23:11

nelsongames (3998 views)
2018-04-24 18:15:36
Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!