I am gonna be writing java code to plot 3D point clouds. Someone suggested me to go for java 3D libraries however it is apparently dead (this reference) and not apparently good idea go to with JMonkey either (same reference).
That link was posted in 2009 and we are in 2012.
All I want to do is to plot a dense 3D point cloud, say 5 million points, and to be able to rotate it / or zoom in real-time. I know the algorithms for rendering and stuff however I need a set of 3D java library with active community and support ( if any).
Please consider Desktop and also Web applications while suggesting me the solution.
Thanks a lot
and not apparently good idea go to with JMonkey either (same reference)
What you reference there is more than three years old, ancient in terms of technology.
jME has come back in a big way since then. jME3 is it an extraordinarily stable beta with Android support, improved physics support (both JBullet as well as a native wrapper), an SDK with scene editor, lots of user-contributed plugins, and an extremely active community.
There are a number of successful games making use of it as well, most notably Mythruna and 3079.
What you're looking to do is easily accomplished in jME and we'd invite you to come on over and try it out. http://jmonkeyengine.org
Not a scenegraph, but LWJGL offers an easy wrapper around OpenGL, so you could quite easily construct a list of quads to represent your points and setup/modify a view to display and rotate them depending on user input.
This should work in applets also to cover your web targets.
jzy3d
is what you are looking for.
Jzy3d is an open source (BSD) java library that allows a rapid display
of 3d scientific data, either surfaces, scatter plots, bar charts, and
lot of other 3d primitives. The API provides support for rich
interactive charts, with colorbars, tooltips and overlays. Axis and
chart layout can be fully customized and enhanced.
I would use JavaFX for this. It is already included in JDK 8 and the project is well alive.
Contrary to LWJGL, there is more and better documentation. Also LWJGL being a thin wrapper, will force you to learn OpenGL as soon as you need to do any transformation, and that will take you some time.
Jzy3d is a higher level API but the tutorial is not free.
JME3 is overkill and, as long as my limited experience with it taught me, you'll need to use Blender to create the model (I might be wrong).
There is a lot of documentation for JavaFX online. If you don't mind buying a book, "JavaFX for Dummies" is quite good, although basic.
Related
I have never done any 3D programming and will be working on a 3D aircraft crash simulation. I am going to do it in Java, though I know C++ is probably more popular for this sort of thing, but I have no experience with it and a limited time frame.
Could anyone recommend any engines or wrappers? I know there is Java3D, but isn't it getting a bit old now? I have also seen JMonkey Engine, although that is for games I am sure it would be fine for simulation software?
Thanks!
You're going to have to firm up your fidelity requirements before you're going to get a truly useful answer to this. Some observations:
Java 3D - It doesn't appear to have had much active development since 2008 (though it looks like it's been ported to use JOGL). If it does what you need, go ahead and use it, but don't expect it to get any new features anytime soon (unless you want to write them yourself). Since it's mainly a scene graph manager, it may be of use for display, but it doesn't have any physics simulation capabilities.
JOGL - This is the OpenGL bindings for Java. Its most recent stable version is also about 4 years old, but there are indications it's undergoing some development to take advantage of newer OpenGL features.
jBullet - This is a physics engine for gaming purposes. It's essentially a Java port of the C++ Bullet Physics engine.
jMonkey - This is a gaming engine, which combines both a rendering engine (Java 3D) and a physics engine (jBullet) into a single package.
Back to my main point. If your requirements can be satisfied with a game engine, then you're okay to go with something like jMonkey or if you want to strip it down, just use JOGL and jBullet.
The downside is that most physics engines used for gaming don't deal with aerodynamics so much as collision detection and constrained movement. There appear to be a few flight simulator extensions for jBullet, but I can't make any recommendations about their quality... I suspect they too are for gaming purposes.
If you want to start dealing with structural failure simulation for the purpose of engineering analysis and the like, you might be able to get these tools to do the rendering and at least a small part the physics associated with it. But a physics engine tuned for gaming is not well suited to this kind of analysis. For that you will need a professional engineering package, or a professional engineer with a background in aeronautics, mechanical engineering, modeling and simulation... and who knows how to program in Java.
As for
what happens to other aircrafts in the airspace, actions taken by
aircraft controllers and the debris field.
Most of this is not going to be included in any physics engine, even one suitable for engineering analysis. There's some aeronautics and mechanical engineering involved, but that only constrains what's possible. What you're talking about deals with human behavior under stressful situations. That's a focus of much research, but you're unlikely to find anything available either as open source or commercial software to satisfy that part of your project.
Bottom line, get a better understanding of your requirements. If you don't have that understanding up front, you're going to be solving the wrong problem.
Other alternatives are:
lwjgl (website) A gaming library including GL binding and support for controls and sound .
ode4j (website) A 3D game physics library. This is a Java port of the ODE C/C++ physics library.
just joined this awesome siteā¦
Ive recently been working in XNA on C#, making a library for that framework.
Ive gotten interested in java at was going to try making a similar library for java.
Thats when the problem arrived, there doesnt seem to be a standard 3d renderer on it.
Ive heard of JOGL, but it seemed to be discontinued (project inactive), and i prefet high level anyway,
Then I saw jMonkey and espresso 3D, but both seemed less efficient and less pretty then directx.
JavaFX discouraged me by saying that its for rich internet content.
My question is, which out of these are optimal. What is the technical difference between OpenGL and DirectX, are jMonkey and co. Actuallh effective? And if not is there a framework similar to XNA for java?
I only ask you name some and point me in the right direction, as this got me a bit confused after the 1 way .NET xD.
Also, as this is my first post here, feel free to correct any mistaked I may have made.
I think jmonkeyengine or jogl are probably the best choices, but it really depends on what your doing. Jogl looks like its still going but is now part of a fuller set of libraries, jogamp, which covers sound and gpgpu programming as well as graphics.
http://jogamp.org/
Jogl is essentially a java wrapper around OpenGL, so will be low level and require to write shader code in order to do anything modern. Jmonkeyengine is probably more the sort of thing you're after since it comes with a lot of prepackaged functionality (including its own IDE).
The real standard 3D API for Java -- in the sense that it's the one that Sun once considered "official" -- is Java3D, which is a scene graph API, something like Open Inventor. I never liked it much, and the level of support these days is pretty low. But it's worth considering, if only for completeness.
I realize JavaFx 2.0 has only been out for a short time but was hoping someone is aware of an FX 2.0 game engine ( or even such a project in open source development )? I've been unable to find one- so if you do please point me in the right direction.
I'm also wondering how JavaFX2.0 will change java game programming. From what I've read and the small experiments I've made I can definitely say it is much more pleasant to code in. And I believe it runs on a faster hardware accelerated graphics engine than regular Java swing or awt based stuff. But is it complete enough to support an entire game framework of any complexity?
JavaFX is great for simple browser based / 2D games - the kind of areas where Flash is currently most common. Reasons:
Great performance for 2D apps (good use of hardware acceleration under the hood)
Very easy to skin with CSS - web designers will love this
The new JavaFX 2.0 API is very usable from pure Java (or other JVM languages like Scala, Clojure)
Cross platform, so can reach the largest possible audience
It's unlikely to be suitable for complex / high performance 3D games where you will need a proper OpenGL game engine like jMonkeyEngine.
I think the jury is still out with respect to the games in the middle ground (shoot-em-ups, 3rd person view RPGs, RTS games etc.). These games don't necessarily need a full 3D engine but do need good, smooth graphics performance. I suspect JavaFX would be fine for these on modern hardware, but I'd strongly suggest doing a quick prototype just to check the performance meets your requirements.
javaFx is not much more than a GUI toolkit like Swing, but with some extras. It is already possible to render a proper game engine into a javafx node. Here is a dome showing this.
http://www.java-gaming.org/topics/lwjgl-javafx-integration/27801/view.html.
But this does not solve the problem to lock the mouse for first person like games.
Colleagues of mine are using Java3D for visualizing results of finite element simulations. The problem is that Java3D seems to be somehow dead, and it is a pain on OSX. This is one of the reasons we are looking for alternatives.
Quite a lot of work has gone into our current implementation based on Java3D, so the question is how much effort it would be to move away from Java3D.
JOGL is one option, but looks like a lot of work.
Has anyone suggestions for alternatives? Any experiences with such a migration?
JOGL provides a direct access to OpenGL functions. These functions are mostly low level draw functions, and you have to deal with the 'state machine' nature of OpenGL while you are programming.
Java3D abstracts this state machine. It allows you to define a tree of graphic objects, placed in a virtual scene, and rendered by a camera. The manipulation of these graphic objects is easier with such a tree structure. Then, it's up to Java3D to walk through this tree and call the OpenGL drawing functions.
This kind of library is called a scenegraph. There are many scenegraph libraries in java, some are implemented on top of JOGL. I don't have a list, but this keyword will help you in your research.
In our project, we tried 3 or 4 different libraries, but no one filled all our requirements. We ended writing our own scenegraph library (on top of JOGL).
jMonkeyEngine, Ardor3D, jPCT or Xith3D are much better options these days.
JOGL is indeed a good option. However, it's simply a wrapper library for OpenGL. That means you'll still have to do a lot of the legwork yourself. If you're comfortable with that and it suits your needs, it's not actually all that difficult. But it might be a bit time consuming and not knowing your current code-base I don't know how easy the transfer is.
You could however go for an engine which might use JOGL. Something like JMonkey Engine to purely name an example. If you look, you'll surely find some others. Have a look at those, their ease of use and their functionality to see what best suits you. They probably won't take all the work away from you, but they might make it a bit easier.
See also this Java 3D forum thread : Java3D viability questions... https://forums.oracle.com/forums/thread.jspa?threadID=2150209&tstart=15
August, InteractiveMesh
I use JOGL 2.0 (which is a low level Java binding for the OpenGL (and OpenGL-ES) API. I have recently helped someone to revive Java3D. Now, it relies only on JOGL 2.0 and it works better, especially on Mac OS X. You can find the source code here:
https://github.com/hharrison/java3d-core
Let's have fun. It is actively maintained anew ;)
P.S: I wrote a detailed article to explain how to use the very latest version of Java3D (1.6) here.
I'm looking for a 2D scene graph library for building GUI applications. It should be fast, using Java2D and be compatible with Swing (embeddable in a Swing app and also display Swing components). Support for animations is a plus.
Do you have any experience with some of the libraries?
Are there any libraries that I have missed?
I have to add that I'm not totally offended by a Scala library.
Project Scene Graph
seems reasonably fast
only GPL (no LGPL)
supports animations
abandoned 2 years ago
as former part of JavaFX it's a Sun product
G
dunno whether it's fast
LGPL
no animations
last version Dec 09
Piccolo2D
for "zoomable user interfaces"
looks like an academic project
google code project with high activity
BSD licence
dunno if it's fast
dunno if it does animations
Pulpcore
is a game library
is targeted at applet deployment (using it as application is hacky)
very fast
supports animations
no development for 2-3 years
probably no Swing support at all
jTem
part of a bigger project (at first glance)
freeBSD license
no animation support
looks very minimal
Amino is another one created by Joshua Marinacci. It's very new, but has some interesting features such as CSS skinning, 2D or 3D backends. I am also very much intrigued about its use of an event bus rather than listeners, as that is quite in line with the Scala+Actor stuff I am working on at the moment.
That said, I haven't played with it (yet), so I don't know how good it is.
http://leonardosketch.org/amino
Piccolo2D, "academic work" or not, is well written. It's somewhat limited but does what it promises (a zoom-able graph) and does it fast. It can be used for at least basic animations such as moving, resizing, color transitions, etc but more can be done as it allows "normal drawing" as well. Has pretty extensive support for events for customization (here the "UI aspect" really shines).
It might be good just to try a few with "mocked" up scene to test for performance/features if this is really believed to be an issue. Piccolo is flexible enough to allow manual management if needed -- e.g. at different zooms display less and/or aggregate objects.
Happy coding.