It's not clear where 1.0 and 1.1.0 reside now has your main page been updated?
The version 1.0 hasn't been released yet. There are numerous things to update in the user's guide.
What is the motivation for JavaFX support, just curious, is it really a live project anymore?
It won't take a long time to implement as most of the job is done in JOGL itself. It gives another option for GUI integration in the engine. OpenJFX is a live project even though it's not the API that I would choose for my own projects right now.
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.
Feel free to investigate of course but as I can't even reproduce your bug, there is almost nothing I can do.
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!
This engine must work, I don't want to let my own project die. There is no commercial interest at all. Nobody pays, I do what I can on my spare time. You're right, it's not the kind of thing doable in a few weeks. I won't start implementing this backend without being confident about having enough time to make it work.
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?
It won't be a complete rewrite. Most APIs will simply go on working but the closer they are from some specific implementation details of the API used in the rendering backend, the more they will be subjected to some changes.
I'll preserve the public APIs when it's possible but some core classes might need a complete rewrite without modifying their public APIs.
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.
I won't make any choice depending on Apple's decisions. Apple is unable to maintain cross-platform APIs, it criticizes some of them (OpenGL, WebGL) and it pushs its own proprietary craps (Metal, WebMetal).
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).
Yes, exactly, in ardor3d-vulkan-awt. The developers could go on using Swing, SWT, AWT, OpenJFX/JavaFX, they could use NEWT alone with the new UI API relying on Firefox, NEWT with another GUI API.
Is there an emerging Java+Vulkan community similar to what we have with Jogamp? Probably too early to talk timelines?
Vulkan will be supported by JOGL. I think that I'll really have to give some help to make it happen. Yes, it's too early and it doesn't depend only on me. I still need some time to clean up the mess, move away from Github and implement the missing features in JogAmp's Ardor3D Continuation. Don't expect any serious work on JogAmp's Ardor3D Continuation 2.0 (I'll pick another name) before 2021.
This engine is mostly a one-man show, updating the Java API documentation was extremely time consuming, I'm not paid to work on it, I have only a very little spare time. I want to release a clean first major version first. In my humble opinion, working on this engine will be easier for me when I'm away from Github and when it's more future proof (i.e fully compatible with Java11).