Hi all.
I'm not interested into gaming graphic, but only into science graphics.
So far, my colleagues developed a software that visualise and animate very big 3D Finite Elements mesh.
There are almost 250000 vertices (nodes). We don't need textures for voxels, just standard RGB palette colors.
For the first time, software must be featured enough to allow user to rotate and scale 3D mesh in real time, as well as make and display very fast cross-sections of it.
This new software must be coded in Java language and we want to start with the right 3D API from the very beginning of the project.
What do you think? Should we use Sun's Java3D, JMonkey or xith, or we should leave OO concept and stick with plain JOGL/LWJGL? What API/engine is best suitable for our project?
Sounds like you would basically need to modify native buffer contents fast enough. So choosing from jME, Xith and/or LWJGL/JOGL is all ok (not sure Java3D allows modification of vertex buffers, but I guess it does). Performance wise they should all fit (if any of them does ;)).
:? Right now I'm styding Java3D, because this is the only framework I have a book for.
In fact, I have a book about JOGL too, but I'm not using it because I would like to stick to the OO concept.
It seems that there is no printed book about JMonkey, so what is the best learning path for this engine? You already know what I want to achieve.
- Make sure you have an experienced programmer at hand (preferably yourself ;)).
- Conceptually you can learn about the scene graph idea from the Eberly book (search for book on these boards).
- Learn about OpenGL basics (probably while programming very small examples with lwjgl directly).
- Use Wiki and code examples to get started with jME :).
to be honest boundary representation schemes don't lend themselves that well to volume visualisation…
especially if you are dealing with a volume with poorly defined/fuzzy iso surfaces…
you could use the marching cubes algorithm which effectively tesselates an iso surface within the volume buffer…
jmonkey would be more than capable of doing that, however if you are dealing with a fuzzy volume this won't work so well plus you may end up with alot more triangles than you bargained for depending on the granularity of your system…
you could also use a texture splatting method which could generate textures by cross sectioning planes parrallel to the view plane through your volume and superimposing/splatting them, again in theorey there is nothing to prevent you doing this with jmonkey but there are issues with the graphics card capabilities and the overhead of generating so many textures on the fly…
also you could use the 3d texture extension that used to be in certain flavours of opengl…i have no idea if any inroads have been made graphic cards wise on this front and i never really looked at it…
or you could do it the only way known to give proper results which is a ray tracer based on the volume rendering equation…
the issue with this is that for real time performance this doesn't lend itself well…
an optimisation that does implement the volume rendering equation and works well for real time performance is philip Lacroute's "Fast Volume Rendering Using a Shear-Warp Factorization of the Viewing Transformation" paper…
here you would just need one of the java opengl bindings such as jogl or lwigl…
although i did port a direct x volume render i had written to jmonkey via render to texture…
other areas that i imagine might be beneficial to volume visualisation in this day and age, it's been over 6 years since i did any work on it, would be shaders and multi-threaded cpus…
i know that alot of solutions back in the day talked about multi-threading as a real advantage for volume visualisation…
First, for me as a newbie, I want to thank you all for the great responsivity on this forum.
I have some basic knowledge in OpenGL (JOGL) and Java3D scene graph so I'll give mu best to learn forward, but at the moment I have to make decision in the right direction on what enegine to learn seriously? jMonkey sounds very interesting, so in the next few weeks I'll give it a try.
p.s.
to @irrisor
I'm the only one and consequently the best Java programmer in the team. All other are C++/C/Fortran programmers.
I'm also skilled Ruby programmer, so I consider my Java knowledge pretty decent, though my coleagues consider it as excellent. 
I wouldn't bet on myself. 
to @ncomp
My intention is not to iron (make it smooth) the surface of the volume. I just have to show 3D volume, make it manually rotate, or make cross section of it. Visible surfaces of voxels don't need any texture - just plain palette color. Note that I already have all data (x,y,z,…) that describe any vertice in the space. Data other than coordinate triplets will serve to calculate the color of the visible surface of the voxel. Nothing else. Next task would be to make animation of travelling through 3D tube for example.
Sorry, byt I don't know what the term "splatting" menas.? :?
where exactly is your data set sourced from?
if it has well defined surfaces in it then algorithms such as marching cubes and splatting will work fine…
a well defined surface would be the wall of a house, a poor one would be a cloud (apologies for the simple analogy just wanted to make sure we are reading off the same page)…
also a major issue is the size in terms of samples/points of your data set…
i was dealing with 16,777,216 points/samples so i needed to optimise how i processed and transformed these points as 16 million matrix operations was obviously not going to be interactive…
the ray tracing algorithm generates colours and opactities per sample/voxel based on the volume rendering equation…
there is no texturing involved…
also have a look at the visualisation toolkit engine (vtk as it's known) as this is designed specifically for scientific visualisation as opposed to jmonkey which in essence is a game engine…
hope that helps…
Thank you for your answer.
I'm not quite sure about VTK and its comatibility with Java.?
On the other hand, my data is sourced from a plain txt file.
It has well defined format and it is quite easy for me to find out what connectivity looks like for any single node in the mesh.
So, in order to find out what elements are in fact surface elements, I can check every node to 8 connectivity scheme.
I expect it to be fast process. Than, the only thing I have to do is to render surface elements in various colors, depending on the additional data associated with every node.
Much bigger problem for me will be to make plain cross-sections, as I will have to introduce new nodes and calculate additional data for them, based on the additional values of the surrounding nodes.
There may be many cross-sections, cross-sections through already existing cross-sections etc.
All this calculations must be done very fast and manual rotations of the model must be performed fast and smooth.
Do you have some other idea on how to achieve same thing, cause I must admit that my knowledge in visualisation is pretty poor.
Thanks again.
There are in fact two issues (tasks) whit this.
The first one is that all manual transformations must be done on all vertices (surface & internals) that the mesh consist of.
Second, for me it is quite enough to render only the surface elements of the mesh.
You described this procedure very well in the 2nd paragraph of your latest post.
Do you have any idea, or algorithm on how to get this done:
then i would start defining the volume or it's iso surface as line loop and then a mesh...
But, in fact, I don't quite understand here what you point to and why I would need this.?
I guess that this is related to anti-aliasing of the mesh surface.
If I'm right, I can assure you that jagged surface is quite good for me.
Maybe, I will have to display additional data in the status bar when mouse approaches to some of the surface vertices, so it would be wrong for me to change their positions (vertices must stay visible on the surface). Of course, this doesn't apply to vertices in the cross-sections as they are interpolated, but special note or attention about that can be given at the status bar in such case.
rasa said:
There are almost 250000 vertices (nodes).
I am pushing up to 300,000.00 TRIANGLES inside the viewport, textured, various particle effects and post-processing shaders here with jME on FULL-HD resolution and 4xAA with more than 100 FPS.
The PC is 2 years old.
performance is not an issue here as far as i can say. There are always ways to win your FPS back ;)
Glad to hear it! 
8)
rasa said:
Thanks again.
There are in fact two issues (tasks) whit this.
The first one is that all manual transformations must be done on all vertices (surface & internals) that the mesh consist of.
Second, for me it is quite enough to render only the surface elements of the mesh.
You described this procedure very well in the 2nd paragraph of your latest post.
Do you have any idea, or algorithm on how to get this done:
to define an iso surface in a volume set as a triangle mesh the main algorithm used out there is marching cubes...
i'd recommend you have a look at that..
although i would say have a look at marching squares first as marching cubes is just an extension of it...
i have an example program for marching squares i wrote for contour analysis, here, which may or may not be helpful....
after that i would load up my volume and then use jme to define each node/vertex as a point using the Point class...
i'd start on a tesselation algorithm after that...
but get as far as there and you might have a better handle on what you are up against...
jme is very straight forward to learn and the community is always busy, friendly and helpful...