A new binary build available soon

Hello

The examples based on ardor3d-craft are working.

I'll add a roadmap into the project:

1.0.0:
- 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)

1.1.0:
- Constructive Shape Geometry
- BVH import
- Support TrueType fonts (I don't remember where the contribution on this is :s)
- OFF import (very low priority)

2.0:
- GLTF import and export
- Vulkan renderer
- ardor3d-web-ui
- Improvements of ardor3d-math in order to compete with JOML
- A brand new name for the project?

P.S: I've just uploaded the new binary build.

Hello

JogAmp's Ardor3D Continuation will use the JogAmp's bug tracker from now on:
https://jogamp.org/bugzilla/buglist.cgi?product=Ardor3D

I'll add the known bugs into it very soon.

I've just updated the wiki section about JogAmp's Ardor3D Continuation:
https://jogamp.org/wiki/index.php?title=Main_Page#Ardor3D

On 9/5/19 12:42 PM, gouessej [via jogamp] wrote:
> Hello
>
> JogAmp's Ardor3D Continuation will use the JogAmp's bug tracker from now on:
> https://jogamp.org/bugzilla/buglist.cgi?product=Ardor3D
>
> I'll add the known bugs into it very soon.
>
> I've just updated the wiki section about JogAmp's Ardor3D Continuation:
> https://jogamp.org/wiki/index.php?title=Main_Page#Ardor3D

Great Julien, thank you!

~Sven

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.

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.

~Sven

Hello

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

Hello

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.

Hello

I'll switch to JOGL 2.4 in JogAmp's Ardor3D Continuation 1.0 when it's released.

Most of the objectives in the version 1.1.0 will be moved to the version 2.0 and I won't support TrueType fonts directly.

I'll confirm that I'll probably stick to embedding Servo to create ardor3d-web-ui. It seems to be possible to bootstrap the OpenGL context created by WebRender from the OpenGL context of the (Java/JOGL) embedder (big thanks to Philip Lamb for the tips):
https://github.com/philip-lamb/servo/blob/phil-ss2-headless/ports/libsimpleservo2/capi/src/lib.rs#L495
https://github.com/philip-lamb/servo/blob/phil-ss2-headless/ports/libsimpleservo2/capi/src/lib.rs#L813

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.

Hello

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.

Reference: https://jogamp.org/cgit/ardor3d.git/commit/?id=46335e7a94404af90d62669e77380d9d23ef324e

I'll update the binary build very soon.

Hello

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.

Hello

I started investigating WebGPU support a few days ago. As a first step, I tried to use OpenJFX WebView to run WebGL but it didn't work and it will probably never work:
https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-August/031736.html

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.

Hello

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:
VNCVNCVNCVNC

but it looks like this:
VVVVNNNNCCCC

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.

Hello

I've just removed the misleading interleaved data mode. Unfortunately, the automatic Java documentation generation is broken anew, Maven is becoming really extremely annoying, I tried this suggestion without success:
https://stackoverflow.com/questions/15639185/how-to-skip-test-api-docs-in-maven-javadoc-plugin

Hello

The grabbed mouse manager is unsatisfying, I'll have to find a native API to get the relative mouse move because the current solution drives my game unplayable on a slow machine under GNU Linux.

Hello

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.

Hello

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.

I've just uploaded the binaries and the API documentation.

Gradle build has been fixed. Please use at least Gradle 7.2. I removed the obsolete Gradle wrapper.

Hello

I'm currently preparing some major changes:
- I'll move the current modified version of Paul Lamb's Sound System into ardor3d-audio and ardor3d-audio-joal from TUER to JogAmp's Ardor3D Continuation. It has nothing to do in my own project and it could be helpful for others.
- Java >= 17 will be necessary to build the engine.
- I'll drop Maven and Ant, I'll use only Gradle to build the engine. I don't want to undergo Maven's regressions anew in the future. I want to ensure that I can generate the Java API documentation with Gradle; when it's done, I'll delete both Maven files and IDE specific files (that can be generated with Gradle anyway).
- I'll have to clarify the unit tests one day. I'll probably use TestNG instead of JUnit and no mocking API.

I've just committed the source code of ardor3d-audio and ardor3d-audio-joal :) Please notice that the Ardor3D sound system does NOT rely on Java Sound. You can compile it without depending on the module named "java.desktop", you can use a compact profile and it relies on Ardor3D Math which helps to avoid creating temporary Vector3D objects to use the spatial sound, you can pass directly Vector3 instances, it's much more straightforward and less error prone. Those subprojects can only be built with Gradle as I'm really going to drop Maven soon.

Java 17 is required to build Ardor3D.