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.