a third sample program is now available (early access): FXPropellerPuzzle. The Java 3D scene of an animated propeller engine is rendered into several puzzle pieces. The puzzle board is resizeable from 2x2 up to 8x8 pieces on a screen of 1200 pixels height. This application is using source code of the JavaFX sample 'PuzzlePieces'.
the source code of the sample program FXPropellerPuzzle and for the underlying FXCanvas3DImage API are now available for download. Following changes were made to solve the issues:
- Picking and dropping of puzzle pieces now (should) respond with no delay. The functions Node.toBack()/toFront() for sequence members were replaced by
package function pieceToFront(piece: PuzzlePieceComponent): Void {
delete piece from puzzleGroup.content;
insert piece into puzzleGroup.content;
}
package function pieceToBack(piece: PuzzlePieceComponent): Void {
delete piece from puzzleGroup.content;
insert piece before puzzleGroup.content[0];
}
- To adjust the number of puzzle pieces according to a new size of the puzzle board missing pieces now are added resp. surplus pieces are removed. Replacing all pieces by a new sequence was more time-consuming.
- The shuffle and solve animations seem to run a little faster, but they still might be slow for more than 7x7 pieces.
Inspired by the JavaFX sample 'VideoCube' I started a new feature and a new sample program FXTuxInTheBox. Six simultaneous views into a Java 3D box are assigned to six JavaFX faces which build the shape of a box by applying the JavaFX effect PerspectiveTransform. The underlying FXCanvas3DMV API supports multiple views into Java 3D scenes. An 'early access' version can be launched at http://www.interactivemesh.org/testspace/j3dmeetsjfx.html
JavaFX 1.2 doesn't provide a script-language-based and hardware-accelerated 3D API. Neither in the FAQ nor at JavaOne 2009 any announcements were made. Concerning 'JavaFX Prism' no details are available yet. Early in 2008 Sun interrupted their contributions to the Java 3D API for the JavaFX 3D Scene Graph (SG3D at JavaOne 2008). There are rumors that it will be released this year, or later.
If 3D support is now needed or desired in JavaFX, an alternative might be integrating one of the lower or higher level 3D Java APIs. Lower level Java APIs are JOGL (Java binding for OpenGL) and LWJGL (Lightweight Java Game Library). Higher level scene-graph-based Java APIs are: Ardor3D (fork of jMonkeyEngine), Aviatrix3D, Java 3D, jMonkeyEngine, JUniversal3D (fork of Java 3D), and Xith3D. All of them do 3D rendering at least per OpenGL. Java 3D and JUniversal3D render per DirectX/Direct3D, too.
The most common 3D rendering target is a heavyweight component derived from 'java.awt.Canvas'. This is the fasted Java GUI component available. Unfortunately, JavaFX doesn't support heavyweight components in its scene. So, 3D Java APIs have to provide a lightweight component for 3D rendering. This can be added via a SwingComponent to the JavaFX scene.
As InteractiveMesh is also committed to Java 3D and its fork JUniversal3D, it was and is a challenge to make current and future Java 3D applications runnable under JavaFX as they are runnable under Java/Swing and Eclipse/SWT. But, it looks as if no other 3D community has published a JavaFX 3D application powered by their 3D API so far. Am I right?
Lightweight 3D rendering is not as fast as 3D on-screen rendering by a heavyweight canvas, because in lighweight 3D rendering all pixel data have to do a round-trip GPU -> CPU -> GPU instead of to be drawn directly into the display.
JOGL's lighweight component 'javax.media.opengl.GLJPanel' provides an actually faster alternative: direct rendering into a Java 2D back buffer (Swing back buffer ?) to avoid the round-trip. But this is declared highly experimental and isn't available as public java- or javax-classes.
Therefore, I'm curious if JavaFX will provide high speed back buffer 3D rendering and if this will be available for Java applications as well.
Three of four samples are now ported to JavaFX 1.2 and available for launch and download. The Java APIs FXCanvas3D and FXCanvas3DImage are not affected and their current releases can still be used.
Ah, it's such a shame that the 3d accelerated version of JavaFX was thrown out for what seems (to me) like political reasons. From what I saw it was well on its way and had really great promise. :(
A different approach to synchronize Java 3D and JavaFX rendering can now be tested with the sample program FXCharacterCube SB 4.0. A more serialized graphics device access of both pipelines reduces the time-consuming native 3D context switches. In addition, the two off-screen buffers can be replaced by a single one. This saves the time it takes to copy the buffer data.
Even if the public APIs of Java 3D and JavaFX provide only limited or no rendering callbacks the above mentioned approach results in a faster running rendering loop in comparison to the current FXCanvas3D API 2.0.
- Stereoscopic JavaFX 3D rendering
Anaglyphic motions or images provide a stereoscopic 3D effect when viewed through colored filters. Java 3D's off-screen rendering and left/right eye viewing capabilities allow real time stereoscopic 3D rendering on every CRT or LCD monitor. Only anaglyphic glasses with red-cyan filters (left-right) are needed to see the stereoscopic 3D effect.
The Java 3D Swing based stereoscopic API was ported to JavaFX: FXCanvas3DAnaglyph. The sample program FXTuxInStereo allows to switch from stereoscopic to monoscopic viewing. When rendering is in monoscopic mode the prototype of the new single buffer FXCanvas3D API is used.
Hi sancelot, thanks for your source code analysis and interesting question.
- Neither the Java 3D/JavaFX sample programs nor the underlying lightweight canvas APIs create new threads for 3D rendering tasks. However, they are dealing with existing threads of the Java, Java 3D, and JavaFX implementations via Locks and Conditions.
- JavaFX is a single-threaded engine. User actions, animations, and rendering run in a sequential manner controlled by the EDT (Java's core Event Dispatching Thread).
- The (almost) GUI-independent engine of the scene-graph-based Java 3D API is heavily multi-threaded. Its master thread MasterControl takes care of the central message dispatch and thread scheduling (state updates, animations, rendering). In its J3D-Renderer thread all OpenGL calls regarding the off-screen rendering loop are done per JNI (Java Native Interface). No calls are executed under the EDT. The OpenGL pixel buffer (pbuffer) is copied into a BufferdImage object by calling glReadPixels(..). Now it is up to the lightweight canvas API to initiate the repainting of the corresponding GUI-component.
- So, Java 3D does not render in response to a special JavaFX request. But, vise versa Java 3D requests JavaFX to repaint. As reading and painting of the rendered pixels have to be executed one after the other the J3D-Renderer thread and JavaFX' EDT have to be synchronized.
August
Edited by: InteractiveMesh on Sep 16, 2009 3:51 AM
I think your work regarding 3d and javafx seems to be the right way to go today.
however, Can you please provide me the very basic demo code that integrates only a very basic cube in a 3d canvas in javafx (I think I need implementation of FXCanvas3DImage ?)
I tried to compile and run tuxinthebox demo, but failed at runtime with javafx 1.2
Best Regards
Steph
This topic has
17
replies
on
2
pages.
1
|
2
|
Next »
Email this Topic
Edit this Topic
