I have an application written in in Java 3D. As Java 3D is now virtually dead I am thinking about converting the code to JavaFX (JavaFX 8 supports 3D objects).
The question is whether it is relatively simple to convert Java 3D code to Java FX code?
Are there straightforward counterparts of Java 3D methods in JavaFX or would it be more like a total redesign of the code?
Here is a little list of packages used in the Java 3D code:
javax.media.j3d.Alpha;
javax.media.j3d.Appearance;
javax.media.j3d.Behavior;
javax.media.j3d.BoundingSphere;
javax.media.j3d.BranchGroup;
javax.media.j3d.Canvas3D;
javax.media.j3d.GeometryArray;
javax.media.j3d.LineArray;
javax.media.j3d.PointLight;
javax.media.j3d.Shape3D;
javax.media.j3d.Switch;
javax.media.j3d.Transform3D;
javax.media.j3d.TransformGroup;
javax.media.j3d.WakeupOnElapsedFrames;
javax.media.j3d.WakeupOnElapsedTime;
javax.vecmath.Matrix4f;
javax.vecmath.Vector3d;
javax.vecmath.Vector3f;
Java 3D isn't dead, you're completely wrong as you can see here. There is a wide choice of scenegraph APIs more capable than JavaFX 3D API which is particularly poor in my humble opinion.
I don't know what gouessej is saying about Java 3D not being dead, there will not be feature development for Java3D going forward.
However he/she is correct that the base JavaFX 3D API is very lacking in features.
If you want to port your application to JavaFX 3D, you will have to rewrite the rendering portions to match the new JavaFX API. From the list that you provided only PointLight and Shape3D have DIRECT counterparts. Alpha transparency is an undocumented unsupported feature as of 8u40 that will get compiled into the official build for Java 9. The F(X)yz team has a demo of it working just fine but we had to recompile the platform from sources ;-).
You are not alone though, there is now free open source third party support via F(X)yz: (shameless plug....)
http://www.fxyz3d.org
Related
I'm developing applications to display very large lidar/sonar datasets (millions of points). QML/Qt seems an attractive platform, since in theory one can quickly define the UI with QML, and implement the "back-end" with high-performance C++. The QtDataVisualization package also seems very useful, especially the Surface3D and Surface3DSeries components for my application. But the provided examples either demonstrate a pure QML approach - which is impractical for my application, with millions of points - or a pure C++ ("widget") approach - which loses the benefit of quickly designing the UI with QML and is locked to a desktop computing platform.
Can someone point to a working example showing how to set QML Surface3DSeries data from C++? This seems theoretically possible from the documentation, but I have been unable to do it, and none of the provided examples demonstrate it. Is this even possible, or is Qml/Qt "broken" in this regard?
Thanks,
Tom
It is possible, but not officially supported and not documented.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Since Qt can handle in normal way OpenGL, it is cross-platform, can handle mouse, keyboard, gamepad etc. What are the disadvantages of using Qt with OpenGL instead using OpenGL with extensions?
What are the disadvantages of using Qt with OpenGL instead using OpenGL with extensions?
Your question is malformed. Nothing stops you from using Qt with OpenGL and with OpenGL extensions.
You can use Qt to manage the OpenGL window, while using direct OpenGL commands with extension to render. You are not required to use Qt's OpenGL interface to render in an OpenGL window.
Qt does not provide "additional opengl functionality." It cannot provide "additional opengl functionality." It isn't part of OpenGL, so it can't make OpenGL features magically appear.
There are no OpenGL extensions for mouse, keyboard, gamepad, or any of the other things Qt handles. Qt's windowing functionality and OpenGL extensions are two completely different things. And they are completely orthogonal; nothing stops you from using Qt+OpenGL and OpenGL extensions at the same time.
Well, unless you stop yourself. See, Qt has this OpenGL abstraction layer. This is a set of wrapper classes around OpenGL: QtOpenGLShaderProgram, QtOpenGLVertexArrayObject, and the like. If you use that, you don't directly make OpenGL calls; you make Qt calls that make OpenGL calls for you.
If your question is whether to use Qt+OpenGL directly vs. using Qt's OpenGL abstraction layer, that's a different matter.
The first problem is that Qt's abstraction layer is bound to OpenGL ES 2.0. While it occasionally offers features that ES 2.0 can't do, it is primarily intended as a class-ified implementation of ES 2.0. So by using ES 2.0, you're effectively giving up using lots of desktop OpenGL features.
Not "extensions"; core features.
For example, you cannot use integers for vertex attributes with Qt's abstraction. The QtOpenGLShaderProgram class doesn't allow it. All of its setAttributeBuffer calls assume that you're calling glVertexAttribPointer. It has no mechanism for calling glVertexAttribIPointer. And that has been core desktop OpenGL for nearly a decade.
Note that this is just one feature. Other things Qt doesn't have wrapper class support that are part of core desktop OpenGL (this is not a comprehensive list):
Separate programs
Sampler objects
Separate attribute formats
These are not bleeding-edge hardware features; most of them have been around for half a decade.
QtOpenGLFunctions is similarly limited to OpenGL ES versions. That leaves plenty of non-extension desktop GL stuff on the table that cannot be used through their abstraction.
Also, because Qt's abstraction is around ES 2.0, it doesn't care about core OpenGL contexts. For example, it still has non-buffered vertex attributes (setAttributeArray). That's not legal in core OpenGL, and again hasn't been legal for nearly a decade.
So if you want to actually use core desktop OpenGL functionality, the Qt abstraction layer is out.
Then, there are places where Qt's abstraction just doesn't match how OpenGL works.
For example (and this is a personal pet-peeve of mine), QtOpenGLBufferObject is typed. That is, the binding type is part of the object. This is not how buffer objects work!
OpenGL buffer objects aren't typed. It is perfectly legal to perform an asynchronous glReadPixels into a buffer, then bind the same buffer for use as vertex data. That's not possible with Qt's class abstraction. And it's not like this is something specific to desktop GL; OpenGL ES works the same way.
Similarly, for reasons best known to themselves, they put the vertex attribute specification functions (the equivalent to glVertexAttribPointer) in QtOpenGLShaderProgram. Why are they there? While vertex attributes do have an indirect connection to a program, they're not a direct part of the conceptual program interface. OpenGL doesn't work like that.
So those are the biggest problems with Qt's abstraction layer. If you can live within those restrictions, feel free to use it. For people making desktop OpenGL applications, they may be too restrictive.
You (OP) wrote in a comment to a different answer:
Extensions provide functionality that the core of OpenGL doesn't provide when Qt itself won't be created for providing additional opengl functionality. It was like a addon for users.
I think you completely misunderstood what OpenGL extensions are and how they work. OpenGL extensions allow to add new features to OpenGL (which might actually be included into a later core version) and/or to expose vendor specific functionality like access to special GPU functions present only for a very specific narrow range of GPUs.
Qt on the other hand offers a framework for applications that deals with operating system specifics in a portable way. Qt and OpenGL are completely orthogonal to each other and nothing, that OpenGL extensions do in any way resembles what Qt does. Qt has a OpenGL integration module, that – among other things – will also load OpenGL extensions if you ask it to; but that doesn't make it a "Qt" thing.
I think you are missing the point. OpenGL (including its extensions that provide some perks that the plain OpenGL does not) is "just" a graphics library intended for rendering 2D and 3D. Qt on the other hand is much more. OpenGL in itself doesn't provide anything but rendering. You can't even create a window (as what you are used to in Windows/Linux) with it. In order to add any sort of handling of the user's input you need an extra layer which Qt (and many other similar frameworks) provides - integration into the window manager of the OS, handling of mouse and keyboard events etc. Qt does also support the OpenGL extensions so you don't have to throw these away if you want to use them.
Whether you need Qt for your OpenGL (with or without the extensions your system supports) tasks or not is something you need to decide for yourself. Qt does offer many nice features that will help you make your OpenGL interaction great however it is a huge overhead and depending on your target system you may have to use a smaller framework with a smaller memory (incl. persistent storage for all the library files) footprint and CPU usage. Other popular choices are GLFW, freeglut and SDL/SDL2 all of which provide at least the basics (window creation and mouse/keyboard handling) to get your application up and running.
I need to load a 3D model (.3ds file) in my QGLWidget (Qt OpenGL widget).
I am looking for a cross-platform solution working under Linux, Windows and Mac.
I have found some solutions on the web, but still have not been able to integrate any of them work in my Qt application:
Assimp: it is not cross-platform and does not support .3ds models
(http://assimp.sourceforge.net/)
Qt3D: it is cross-platform and seeems to be the right choice for OpenGL widgets. Unfortunatelly, I still have not find the way to use it.
(https://github.com/qtproject/qt3d)
Qt Quick: it uses QML files instead of QT widgets.
3ds Loader: http://www.spacesimulator.net/wiki/index.php?title=Tutorials:3ds_Loader
Any suggestion?
You can use Qt3D. It adds 3D content to Qt Quick's cross-platform ability. Apps can be 2D QML applications with a small amount of simple 3D content; through to complex 3D scenes, containing 3D assets - such as complex 3D models, and shader effects.
Qt3D supports 2D and 3D rendering in both Qt/C++ and Qt Quick applications.
You can also load a model object in 3D Studio Max (3DS) format or other standard formats like obj with a perspective camera view using Qt3D.
There are some good tutorials and examples here.
Assimp is written in C++ and used cross-platform in several projects including the Qt Project itself.
The .3ds format seems to be supported eventually unless you use a very old version where it was not added. See the documentation for further details about it:
Common interchange formats
Note the following entry at the top:
3ds Max 3DS ( .3ds )
Im interested in working on JavaFX for the first time. I have a project i am working on, in which i dont have a lot of time to complete. I was wondering if javaFX would be a great platform to animate and make a 3x3 rubik's cube game? With all the mouse movements and rotations, Without having to work out alot of linear Algebra.
Jelinek provides public domain sample algorithms and source code for creating a Rubik's cube in Swing/AWT. You could start with that and try converting it to JavaFX, possibly using a Canvas as the drawing surface.
The 3D capabilities in JavaFX 2.2 are quite limited. There are some samples you could look at in the Ensemble application to give you an idea of what it is capable of. There is a tutorial on the Ensemble 3D xylophone which should help provide much of the basic knowledge required to build your application.
Java 8 will have a much more comprehensive 3D feature set. Such an application would likely be much easier to implement in Java 8 than the current JavaFX 2.2 release. Java 8 is not due for final release until September 2013, but you can download a preview version of Java 8. The preview version does not currently fully implement all of the planned 3D features for Java 8, but does implement significantly more than the JavaFX 2.2 release, especially around concepts like 3D transformations, normal calculations, vector logic, etc which would be required for the implementation.
Is there a 3D polygon in JavaFX (similar to QuadArray in Java3D)?
If there isn't what is the simplest way to create one? Creating two triangles?
If there is no simple way than should I use 3rd party 3D library? But that would beat the idea of using JavaFX in the first place.
I would like the abbility to switch between faces, wire-mode and verts-only-mode.
3D in JavaFX 2.x is pretty limited.
You can create a 3D polygon by creating a 2D polygon and performing a transform on it.
There are some 3D samples in the Ensemble application which demonstrate how to do this (with source code). There is a simple cube sample here.
With JavaFX 2.x, you could implement switches between face view, wireframe view and vertex only view with little difficulty. Other things like complex lighting, effects, mesh loading, realistic shading etc, would be more difficult and would be better implemented in JavaFX 8.
JavaFX 8 will have a much more robust and useful 3D implementation. You should evaluate the capabilities of the current JavaFX 3D demos in Ensemble as well as the proposed JavaFX 8 3D feature set against your requirements and other 3D libraries such as lwjgl to determine what will best fit your needs. Note, JavaFX 8 is not scheduled for final release until September 2013. Over time the proposed JavaFX 8 3D features will be added to the Java 8 pre-release.
I did create a simple 3D software renderer for a JavaFX ImageView which I might open source if interested - it renders bitmaps onto an ImageView though - not directly to the JavaFX scene graph primitives. A similar thing, but using a hardware renderer via the Java3D API was created by Interactive Mesh. Unlike JavaFX 8, it has the advantage of being available today.
Interoperability between JavaFX 2 and the main sets of Java bindings for low level 3D APIs (JogAmp and its main competitor quoted by jewelsea) is already partially implemented. When it is ready, you will be able to use the very latest version of Java3D (1.6.0, the instructions to install it are here) or any scenegraph supporting JOGL 2.0 including Ardor3D, JMonkeyEngine 3, Xith3D, ... There are already some applications mixing JOGL 2 and JavaFX in the same window but not in the same panel, for example Energy3D.
Experimental 3D shapes in JavaFX 2 are available in the jfx3D project at google code, also see my blog at designjk.
Jim Kay [jimbo8]
https://wikis.oracle.com/display/OpenJDK/3D+Features
JavaFX 8 includes a full 3D library. I currently am working with it, but it can be buggy + it's not even fully ready for dev's yet, or even close for the general release.