I was wondering if there are any plans to allow programmers to "get under
the hood" in Java3D.  By this I mean, get access to lower level rendering
handles (ie. OpenGL context's, window handles, etc) and perhaps the ability
to modify the main rendering loop.

Right now, J3D is a closed system, which makes it impossible to do certain
things that should be "trivial" (and are in Direct3D or OpenGL).  Here are
two trivial examples:

- putting live video in the background:  I want to write a native library
that accesses a video card and puts video into the background before each
frame is rendered.  Using JMF+Java3D Background or Texture nodes is just
too damn slow (a few extra buffer copies here or there kill you).  This is
_easy_ in OpenGL, and if I could get at the OpenGL context and use it in a
pre-render hook, I'd be set.  We tried to just use the "current context"
(ie.  just call OpenGL methods in the pre-render hook) but Java3D makes
lots of assumptions about it's frame-to-frame context, apparantely, so
touching textures screws it up.

- rendering a heads-up-display over the 3D scene by rendering the 3D scene
using a perspective transform, and then a 2D scene using an ortho
transform.  Yes, we can compute where to place 2D objects in 3D so they
appear to be fixed in front of the screen, but this is a pain, and doesn't
work exactly correct (ie.  to do a real HUD, you want to disable
depth-buffering as well, so the 2D stuff overwrites any 3D stuff).

These are just two simple examples, but they are symptomatic of a real
problem with Java3D, namely that it's rendering loop is "closed".  I
realize that it is possible to do some optimization in the main loop if you
close it, but it should be possible for me, as a programmer, to say "screw
the optimizations right now, here's my main loop that does these things" if
I need to.

Other successful high-level graphics packages (ie. Inventor, Performer)
allow access to the low level parts, since they recognize that the package
designer can't anticipate everything everyone would want to do.

Ways I could envision this being presented to the programmer:
- allow me to get the low-level hooks (opengl, rendering context) at runtime
- allow me to disable inter-frame optimization, so that if I screw around
with state, in the rendering state, Java3D will still function
- allow me to replace the rendering loop and have calls to render scene
graphs.  I would love this, since it would allow me to effectively use the
Java3D engine to manage scene graphs, but allow me to integrate my own
funky opengl or direct3d graphics.

Please don't bother with the obvious response:  I fully realize that this
would make my Java3D programs non-portable if I don't handle all possible
low level platforms (which I obviously won't).  However, I suspect that
many people simply don't care about that:  using Java3D already makes my
Java programs non-portable ... I can't run them on a variety of Unixes, or
on the Mac.

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to