Posted by ThomasR on Aug 08, 2019; 6:17pm
URL: https://forum.jogamp.org/A-new-binary-build-available-soon-tp4038575p4039916.html

Hi Julien,

gouessej wrote

Hello

At first, ArdorCraftAPI and ArdorCraftAPITest will be moved into the main project as it makes no sense to me to leave them in separate projects.

Secondly, I'll move the issues into a single file.

After that, I'll update the user's guide, I'll remove all references to Github.

Finally, I'll remove the projects from Github. Please refrain yourself from hosting mirrors of this project on Github.

The main changes on my roadmap for the versions 1.0 and 1.1.0 are these furthers:
- I won't support ES2 and ES3
- I'll switch to Java 11
- I'll add some support of OpenJFX/JavaFX using NewtCanvasJFX
- I'll improve the documentation, fix a few bugs and fix some design inconsistencies in the API for the version 1.0
- I'll implement a very few new features in the version 1.1.0

It's not clear where 1.0 and 1.1.0 reside now has your main page been updated? What is the motivation for JavaFX support, just curious, is it really a live project anymore? Can I vote for one of the bug fixes be related to the thread titled 'Indpependent Textures'? I can do some experimentation on my end, if you perhaps have some notions.

gouessej wrote

The main features planned for the version 2.0 are these furthers:
- The OpenGL / OpenGL-ES backend based on JOGL will be replaced by a backend based on Vulkan (>= 1.1, I'll pick a version of Vulkan converging with OpenCL)
- The current UI API will be replaced by another UI API allowing to render HTML + JavaScript + CSS through a subset of Firefox (Servo). I don't think that I'm able to implement and maintain a totally new UI API alone that would fit into the needs of most programmers and compete with existing ones. It seems more viable to me to allow them to stick to their guns
- GLTF import and export
- improvements of the math API in order to compete with JOML
- I'll choose another name for the engine as it makes no sense to keep the same name for something diverging a lot from the legacy engine

Best regards

Do you have a commercial interest in developing/supporting a Vulkan backend? That seems like a huge job just to do as a hobby, or out of the goodness of your heart!

Would version 2.0 be a complete rewrite of the API, or could applications currently using v1.x simply use 2.0 for the Vulkan backend? What does diverging mean exactly? It's really important especially as it's probably anyone's guess what the future of OpenGL on OS X is.

Would there be equivalent classes implementing com.ardor3d.framework.Canvas like VulkanAWTCanvas, VulkanSwingCanvas, etc? Or would AWT/Swing app be forced to rewrite their UI code. For us, that would might be impossible (prohibitive cost).

Is there an emerging Java+Vulkan community similar to what we have with Jogamp? Probably too early to talk timelines?

Tom