- Inconsistent management of relative and absolute positions in ardor3d-math (for example in the way of managing the position of the buffers)
- Revamping and improvements in the exporters (allowing exports of complicated scenegraphs with hierarchies of nodes)
- Strengthening of the documentation (mostly done but the user's guide still lacks some explanations)
- Import MD2 models more accurately as an option (i.e add an option to split the models into more parts without the useless links that may cause some problems when trying to detect collisions)
- Drive some core utilities overridable (i.e avoid (ab)using the "static" keyword in those utilities)
- Drive all render state utilities overridable
- Switch to JOGL 2.4.0
- ardor3d-jogl-jfx based on NewtCanvasJFX
- Java 11 (but I'm blocked by a bug in Maven)
- Constructive Shape Geometry
- BVH import
- Support TrueType fonts (I don't remember where the contribution on this is :s)
- OFF import (very low priority)
- GLTF import and export
- Vulkan renderer
- Improvements of ardor3d-math in order to compete with JOML
- A brand new name for the project?
You're welcome. Actually, in my humble opinion, JogAmp stuff should be in one place and JogAmp sub-projects should have similar policies on licensing, bug reporting, communication, ... It would be easier to explain for us, easier to understand for newcomers and easier to manage for us.
For example, if we systematically encourage our users to ask their questions preferably here, the people most able to answer (often the maintainers and the contributors) won't have to waste some time on social media and third party websites, they will be able to focus on their tasks and they will have a single place to control. Personally, I won't register everywhere on Internet to answer questions about JogAmp APIs and I'm probably not alone in this case. The situation is becoming problematic on Github because I seriously plan to leave it and it would be a more comfortable change for me if all maintainers refrained themselves from managing issues and pull requests on it because I often have to reply. Charity begins at home, I've repeated for years on StackOverflow that JOGL specific questions should be posted on our forum and I'll leave StackOverflow one day. Github should have been used only as a mirror from the very beginning and it's perfectly fine for me not to use it at all. I don't want to get much visibility at the price of giving much power to Microsoft.
It reminds me that some precious resources should be moved or at least copied into the wiki.
On 9/6/19 9:55 AM, gouessej [via jogamp] wrote:
> Sven Gothel wrote
> Great Julien, thank you!
> You're welcome. Actually, in my humble opinion, JogAmp stuff should be in one
> place and JogAmp sub-projects should have similar policies on licensing, bug
> reporting, communication, ... It would be easier to explain for us, easier to
> understand for newcomers and easier to manage for us.
Julien, what you describe below is surely the default recommendation
and I agree of course.
Official channels are from jogamp.org: git, bugzilla, wiki, forum, etc.
The github repo and others are, as you said, just a backup for convenience.
If anybody answers other questions, they might want to drop the answer in
this forum, wiki, bugzilla and give the source a link.
Just an example to not lose valuable information, if so.
> For example, if we systematically encourage our users to ask their questions
> preferably here, the people most able to answer (often the maintainers and the
> contributors) won't have to waste some time on social media and third party
> websites, they will be able to focus on their tasks and they will have a
> single place to control. Personally, I won't register everywhere on Internet
> to answer questions about JogAmp APIs and I'm probably not alone in this case.
> The situation is becoming problematic on Github because I seriously plan to
> leave it and it would be a more comfortable change for me if all maintainers
> refrained themselves from managing issues and pull requests on it because I
> often have to reply. Charity begins at home, I've repeated for years on
> StackOverflow that JOGL specific questions should be posted on our forum and
> I'll leave StackOverflow one day. Github should have been used only as a
> mirror from the very beginning and it's perfectly fine for me not to use it at
> all. I don't want to get much visibility at the price of giving much power to
> It reminds me that some precious resources should be moved or at least copied
> into the wiki.
maven-javadoc-plugin 3.2.0 contains a fix that will allow me to build the engine and generate the Java documentation with Java >= 11. I compiled maven-javadoc-plugin 3.2.0-SNAPSHOT to ensure that it really helps. I'll use "release", JogAmp's Ardor3D Continuation will go on supporting Java 1.8 but it will become impossible to build it with Java 1.8 very soon, I'm just waiting for the release of maven-javadoc-plugin 3.2.0 to make the necessary changes. However, I might have to drop Java 8 support to ease future proof OpenJFX/JavaFX integration.
I'll switch to JOGL 2.4.0 as soon as it's available for Maven (on Maven Central or on our JogAmp repository).
maven-javadoc-plugin 3.2.0 was released a few weeks ago, I can use it now. My latest commit requires a recent version of Maven (>= 3.6.1) and Java >= 9 to build but it still targets Java 8.
I'll ensure that JNDT works well with JogAmp's Ardor3D Continuation when using Java 11 and I'll probably set Java >= 11 as the minimum required version because I don't want to support pre and post Java 9 builds and Java 11 is still the latest LTS (long term support) version of Java.
That way, WebRender can render the web content in a texture, I just have to pass a texture identifier, its width and its height.
Servo isn't very mature yet, I won't be able to embed it yet and it will probably use WebGPU instead of OpenGL.
I looked at some alternative solutions but I concluded that they would be too slow. WebVector would be enough to render a static HTML page in a PNG but it relies on Swing and I'm not sure that it's suitable for dynamic content. W3C WebDriver and Marionette are suitable for testing purposes but not for real-time rendering.
On the other hand, on the very long term, I'd prefer using WebGPU instead of Vulkan for the next renderer as WebGPU uses Vulkan, Metal, OpenGL, OpenGL-ES and DirectX under the hood. It exposes a Vulkan-like API.
My main concern is that I have a very little spare time to work on my projects. I'll update the copyright year as soon as possible.
Yesterday, I found an inconsistency in the implementations of Vector2.equals(), Vector3.equals() and Vector4.equals(), they consider -0.0 = 0.0 whereas Vector2.hashCode(), Vector3.hashCode() and Vector4.hashCode() don't. I now consider -0.0 != 0.0 in Vector2.equals(), Vector3.equals() and Vector4.equals() exactly like java.lang.Double. If it's a problem for you, you'll have to use another comparator.
I reduced the memory footprint of many hashCode() methods and I updated the binary build about half an hour ago. Before my changes, lots of wrapper objects were created just to pass a primitive number to the main method that computed the hash codes. The hash codes should be the same.
I'll probably add a property to allow disabling/enabling the use of a single representation for zero.
I've found no other cross-platform solution similar to WebView and supporting WebGL. NativeFX claims to work. That's why I had to choose another approach. I remind that I have to use WebGPU to modernize the rendering pipeline and I have to use several Web APIs to get rid of ardor3d-ui on the long term.
I give another try to Bck2brwsr + Dukescript-canvas. I fixed the latter with the latest version of the former, I sent a patch to its maintainer. I try to extend dukescript-canvas API to support WebGL 1, WebGL 2 and WebGPU. It seems to be doable and less time consuming than embedding Servo.
I still want to fix some limitations in JogAmp's Ardor3D Continuation 1.0 before concentrating all my efforts on JogAmp's Ardor3D Continuation 2.0. Preserving most of the public APIs seems to be doable but it's too early to be peremptory about that.
Yesterday, I discovered that the data mode "VBO interleaved" doesn't do what is expected. Let's suppose that you have some vertices with colors and normals, an interleaved VBO should look like this:
but it looks like this:
Its only advantage is the use of a single VBO identifier but I see no performance gain. Moreover, even when interleaved VBOs are implemented correctly, they aren't faster in all cases. Finally, this feature breaks some formats, especially MD2.
That's why I'll remove this feature very soon, it's misleading, brings an hypothetical performance gain, is buggy and complicates the engine. It would be very tricky to implement correctly and the solution wouldn't be very flexible.
In my humble opinion, what matters the most is the size of the data. Interleaved VBOs may marginally reduce the number of OpenGL calls but I no longer expect a consistent speedup from them.
I'll update the JARs very soon but the API documentation will remain unchanged until I fix or work around the problem with Maven.
As I'm completely fed up with Maven bugs and limitations, it's highly probable that I'll support only one build tool in a near future. In other words, I'll drop Maven and Ant in favor of Gradle. I can't stay several months without being able to generate the API documentation. I can't spend months on problems with a build tool and I don't want to spend months on such problems as it's a real waste of time for the engine that needs some fixes and some enhancements.
In my humble opinion, supporting several build tools was a bad idea because I tend to pick one of them and the others are rarely tested.
I'll have to stop using EasyMock in the tests as it uses at least one method no longer accessible in Java 17:
protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte,int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError
The generation of the API documentation with Maven works anew (mvn site).
You can build the project by skipping the tests with -DskipTests or by setting the VM fork count to zero with -DforkCount=0. I'll find a more viable solution on the long term. Mockito seems to support Java 17 unlike EasyMock.
I'll upload the binaries and the API documentation very soon. Java >= 16 is required.