Posted by steve skrabacz on Aug 31, 2015; 2:29pm
URL: https://forum.jogamp.org/Java3D-for-large-scale-CAD-tp4035188.html

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