Java3D for large scale CAD

I've been maintaining a Java3D-based viz tool for over 10 years, used for PLM work (think:  1 million piece parts of CAD, mostly read only).  Over the years the program has been fed by CATIA, STEP, and NX, using the simplest shot possible into an IndexedTriangleStripArray, and often employing com.sun.j3d.utils.geometry.compression.CompressionStream.

We now face a new round of development.  We want to measure & improve initial load time as well as graphics performance (frames per second on rotate / pan / zoom; mouseovers; picking) for a session with 1K, 10K, and 100K parts at a time.  The goal is to scale up to a session that can comfortably display 100K parts at a time (today 100K is sluggish; 10K is very doable).

We're an NVIDIA shop, and have dabbled with CUDA as a means of managing Octrees (as part of some loosely coupled AR work).  But for my Java3D work I've always treated Java3D & the graphics card as black boxes, until now....

So here are a few questions (and BTW I was glad to find this forum, which shows that there's still a heartbeat out there for Java3D...thank you for all your work...360K lines is nothing to sneeze at, and I know how challenging it can be to keep many customers happy...):

1.  The latest jogamp forum entry I found for Java3D source (April 2015) mentions Java3D 1.6.0-pre12, which requires jogl 2.3.1.  Since I'm interested in instrumenting the performance of Java3D, how might I get the source for pre12 (and did 12 ever happen)?  The latest source posted to jogamp is pre10.

2.  Since I only use a small subset of Java3D (no audio; no HMDs; no animation, though I used to use animation quite gratefully in one robot planning project...), I'm tempted to scrap Java3D and go straight to JOGL with Shader-aware rendering.  I would have to reinvent the scene graph & view frustum culling...but I partly believe that this is the piece that might most benefit from any parallelism on the GPU (CUDA or JOCL).  Do you agree with this assessment?

3.  I've read in other posts that the current Java3D for which you've posted source on jogamp (1.6.0 pre-10) strictly uses FFP.  I'm not an expert yet, but I believe that presents two downsides to me:  a) can't run on an Android tablet, since most tablets only support Shader APIs, and b) even if my hardware supports FFP, it's all done in CPU / software, so that there'd be no GPU offloading of the processing.  If you agree with those statements, can you suggest how any future Java3Ds might improve. to embrace the shader pipeline?

Thanks!

Steve

Hi

steve skrabacz wrote

The latest source posted to jogamp is pre10.

The source code reflects the pre12, it is mentioned in this FAQ:
http://jogamp.org/wiki/index.php/Java3D_FAQ
The changes of the pre12 done in April are included.

steve skrabacz wrote

2.  Since I only use a small subset of Java3D (no audio; no HMDs; no animation, though I used to use animation quite gratefully in one robot planning project...), I'm tempted to scrap Java3D and go straight to JOGL with Shader-aware rendering.  I would have to reinvent the scene graph & view frustum culling...but I partly believe that this is the piece that might most benefit from any parallelism on the GPU (CUDA or JOCL).  Do you agree with this assessment?

I don't agree with this assessment but an excellent graphics programmer can do better than Java3D with or without parallelism.

steve skrabacz wrote

3.  I've read in other posts that the current Java3D for which you've posted source on jogamp (1.6.0 pre-10) strictly uses FFP.  I'm not an expert yet, but I believe that presents two downsides to me:  a) can't run on an Android tablet, since most tablets only support Shader APIs, and b) even if my hardware supports FFP, it's all done in CPU / software, so that there'd be no GPU offloading of the processing.  If you agree with those statements, can you suggest how any future Java3Ds might improve. to embrace the shader pipeline?

pre12 uses the fixed pipeline too. I already wrote that there is no plan of improving Java3D. It's actively maintained, the bugs are fixed and that's all. No new features will be implemented in this scenegraph API, the public API will remain frozen.

Rather use JMonkeyEngine 3, LibGDX or JogAmp's Ardor3D Continuation if you need something more modern and faster. As you're not an expert, please don't waste any time in writing yet another 3D engine. You're wrong about Android, it's often possible to use OpenGL ES 1 even though OpenGL ES 2 is available.

Java3D depends on AWT which is not supported under Android. It's a dead end, it's not worth it, drop it if you really need something modern.

Thanks.

You're welcome. I hope that I wasn't harsh with you... I'm the maintainer of JogAmp's Ardor3D Continuation but if you really want a shader based engine right now, JMonkeyEngine 3 is a better choice.