Several issues have been raised in the last day or two. I would like
to respond to some of these. Many of these issues will be addressed
in the 1.3 release of Java 3D. To give you an idea of where we are
headed, I will post a list of many proposed 1.3 features in a separate
message. We are getting ready to start the process for the 1.3 and
1.4 releases of Java 3D.
I want to assure you Sun is committed to Java 3D. It's a crucial piece
of our Java platform strategy that's on its 3rd release since
introduction 2 years ago. If you saw Sun's product announcement
yesterday, you would have seen Java 3D prominently featured. Products
like Facet Decision Systems, Webscope, SDRC 3DDocCom, and INT/Jviewer
are shipping currently using Java 3D. We're hopeful more will join
this list.
There is a misconception that much of our time is spent porting Java
3D to other platforms. Sun delivers Java 3D for Solaris and Windows
(OpenGL and DirectX), only. Java 3D for Linux, IRIX, and HP/UX come from
Blackdown, SGI, and HP, respectively.
With the impending 1.2.1_beta1 release, the DirectX and OpenGL
versions of Java 3D for Windows are now in sync. We will ship final
versions of each at the same time.
Following are responses to some of the issues that have been raised.
1. Transparency
Java 3D does not currently sort transparent objects other than to
render all of the transparent objects after all of the opaque objects.
We fully understand that some solution to this problem is required.
We plan to add depth-sorted transparency in 1.3. This will probably
be via an enum to control the quality of the sort versus time (e.g.,
SORT_NONE, SORT_OBJECT_BOUNDS, SORT_OBJECT_GEOMETRY).
2. Behaviors
A fully general solution to this is not an easy problem (despite
claims to the contrary). The current Java 3D behavior system
guarantees that all scene graph updates that occur from within a
single behavior will be reflected in the same frame. It would be very
easy to further guarantee that all changes from multiple behaviors
using WakeupOnElapsedFrames will be reflected in the same frame. In
fact, that is what the current implementation does. Beyond that, it
gets more difficult. One solution that an application can employ is
to create a WakeupAnd of other conditions and
WakeupOnElapsedFrames(0). This has the effect of synchronizing a
behavior to a frame.
It's worth noting that even if you solve the problem of having the
effect of multiple behaviors appear in the same frame, there are other
issues, other types of synchronization that could be wanted.
Specifically, if the results of one behavior are used as input to
another, the order of execution becomes important. Consider the case
of a behavior that monitors the target TransformGroup of an
interpolator, using the modified transform to calculate the transform
above the view platform (for camera following). Java 3D behaviors are
executed in no particular order; they may even be in parallel,
although the current system has a single behavior thread per universe.
One possible solution is to implement a behavior priority, or some
other form of full or partial ordering on Behaviors that wakeup in
response to the same stimulus. There may be other solutions. For
those of you who are having problems with Java 3D behaviors: what
problem are you trying to solve for which the behavior scheduler is
getting in the way?
3. Bug fixes
Our goal is to make the 1.2.1 release much more stable than 1.2 was.
That's one of the reasons for the delay. We plan to add a second
beta release for 1.2.1 to further this goal. We also plan to
implement a lighter weight "patch" process for distributing bug fixes
to the 1.2.1 release to address bugs that are discovered after the
final release. One thing we need from all of you in order to make
Java 3D a better release is bug reports, with test cases, sent to
[EMAIL PROTECTED] We can't fix them if we can't reproduce them.
4. Source code availability
As you know, the source code for Java 3D is not yet available.
Eventually, we may make the source code of Java 3D available via the
Sun Community Source License (SCSL).
5. Loaders
Our strategy for loaders has been to put out a couple of sample
loaders and encourage the community to add to them. Btw, the loaders
are a good example of why open source doesn't automatically solve the
world's problems. Collectively, the loaders are (or could be) an
open source project that should allow good loaders to be generally
available. In practice, it often doesn't work out that way.
6. Performance
Performance is one of the primary goals of Java 3D. The 1.2.1 release
should perform better and have a smaller memory footprint with fewer
leaks and reduced GC compared to the 1.2 release. We are committed to
improving performance going forward.
--
Kevin Rushforth
Java 3D Team
Sun Microsystems
[EMAIL PROTECTED]
===========================================================================
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".
