This thread, and the performance thread, have raised a number
of issues. I'd like to give our answers/perspective on these
issues. I'll try to hit all the ones that came up. If you
have others, let me know. Note that many of the things I bring
up below are proposed changes for the 1.2 API. We go through
a public review, so things may change.
First, I'd like to give a little history on the implementation.
As the 1.1 implementation was progressing, it became obvious
that its architecture was limiting for both future expansion
and increased performance. So, even before 1.1 was FCS'd, we
began rewriting the entire system with a new architecture.
Java 3D 1.2 alpha1 is the first release of this new system. In
many cases it far exceeds the performance, quality, and stability
of 1.1.*. For instance, the number of Shape3D nodes in the scene
graph should have a smaller impact on performance than in 1.1.*.
Also, all the compile optimizations in 1.1.* have been moved into
the core runtime system, so a wider breadth of applications will see
the benefit. There are a few cases left to optimize more fully, but
the 1.2 system has a much more solid foundation than 1.1. Almost
all of our efforts have been focused on this effort. This is
why the frequency of updates to 1.1 have been relatively sparse.
Next, let me give some of our motivations when adding new API
into Java 3D 1.2. Our initial goal was to make 1.2 a very lightweight
release from an API perspective. We were going to add a set of
minimal "bug fix" API's. These were going to be just the obvious
ommissions from 1.1. This list turned out to be longer than we
had originally hoped. Some of those features have been exposed in
the 1.2 alpha1 release. The complete set of new API will be
in the 1.2 beta release. And, almost all of the new API features
will be implemented in 1.2 beta.
Now let me try to address the variety of issues being raised.
Open Source:
Java 3D is an extension to the Java platform and Sun is in the
process of defining a community source model for standard extensions.
Deployment:
We would love to see Java2/Java 3D bundled with every browser
out there. This is a very hard problem, and we are exploring
all types of solutions. In the short term we are working on
making our integration with plug-in and the new JDK1.3 features
as seamless as possible. This includes completely reworking our
entire installation system. By 1.2 FCS, the install process will
be much cleaner.
Performance:
This one's my favorite. :^) There seems to be a lot of misinformation
about what we do internally. Some folks think we use java bindings
to OpenGL while others think we implement some of the rendering
pipeline in java. Neither are correct. Crossing the JNI barrier
is very expensive. Therefore, we try to get the most bang for our
buck when we have to go to JNI. From the rendering perspective, we
pass AT LEAST one complete Geometry object through JNI for rendering.
In the optimal case, we simple pass a display list id which has
multiple geometry objects in it.
All of our geometry is state sorted based upon its environment,
rendering attributes, texture, transform, and material values.
Our rendering structure allows us to render to multiple screens
in parallel. We have shown this at the past two Siggraph's.
There are lots of topics regarding how we optimize Java 3D. If
you have something specific that you would like to know, just ask.
A lot of people have made the claim that java bindings to OpenGL
will always be faster than Java 3D. My claim is that that should
be the exception and not the rule, unless the application has done
a lot of work to optimize their OpenGL usage. Unless the application
is using display lists exclusively, the JNI overhead is costly in
itself. We have even seen some customers cases where Java 3D is now
outperforming their native viewer code.
My last comment on performance for now is that if you have a case
that is not performing well, send it to us and we'll try to fix it.
Performance is our number one goal for 1.2!!!
Video Texture:
To do true video texture in hardware, the API needs to expose
hardware specific synchronization features. We aren't ready to
go down that pathway yet. But 1.2 does add the ability to have
a texture reference user data directly without making an internal
copy. This should help with this feature.
Audio Rendering:
Our to do list includes a DirectSound audio device implementation.
This will help a lot of the sound performance cases. Since the audio device
is an interface, anyone could write this and share it. Any takers? :^)
Transparency:
It seems that most folks don't know what we do with transparent
objects. The Java 3D rendering order is as follows: opaque objects,
ordered objects, transparent objects. Within the opaque and transparent
bundles we do no sorting. We have discussed adding view sorted transparency,
but different applications want different criteria for the sort. And
sorting on a per geometry basis (which is what we could provide) is not
good enough for most applications. We have added new blending options
that can do order independent transparency, but it has limitations
as well. If you think there is a bug in our transparency handling, let
us know.
Multiple Screens:
This is in Java 3D 1.2 with JDK1.3.
Stereo:
This was a bug in 1.1.2. It is fixed in 1.2alpha1 and the upcoming 1.1.3.
Memory Leaks:
The upcoming 1.1.3 release has mostly fixed this problem. Its architecture
makes it difficult to cleanly fix the whole problem. If you find memory
leaks in 1.2alpha1, please file the bug.
Billboard/LOD:
There are inherent problems with the way we defined the Billboard node.
We've known this for a while. To solve this, the 1.2 beta release will
introduce a new Leaf node called the OrientedShape3D which is a subclass
of Shape3D. Think of it as a merged Billboard/Shape3D node.
For the Billboard/LOD behaviors, we have added in 1.2 beta a new variant of
WakeupOnElapsedFrames() that is passive. It only triggers when something
else causes an elapsed frame. The wakeup condition itself will not force
an elapsed frame. Billboard and LOD have been changed to use this new
condition.
Input/Output/Audio device configuration:
We are prototyping a configuration utility that will handle this
very cleanly. Think of it as a very complete SimpleUniverse utility.
This won't be in 1.2, but will make a future release.
Serialization:
We try very hard to keep the Java 3D API very clean in many different
ways. One thing that we focus on a lot is the semantic cleanliness of a
feature. Does a feature fit in cleanly with all the other features? Will
it constrain us in future releases? Serialization is very difficult in
this respect. Conceptually, it is very simple. And from an implementation
perspective, it could be very simple. Here's the problem. What does it
mean to serialize a scene graph that has been compiled and optimized for
a specific platform. This is one of the questions we need to deal with
to implement serialization. There are many others. It is just a step
too far for 1.2. On the up side, 1.2 beta will have the final declaration
for most Java 3D methods removed.
Resource Control:
This is a grab bag of a number of features. Let me just list the things in
1.2 beta that we've added to help this problem. Threads are created and
destroyed in a consistent/controlled manner, so they show up only when they
are needed and the go away when they should. We have added methods to allow
applications to set the priority of Java 3D created threads and throttle
the renderer down to a reasonable cycle time for simple scenes. In 1.1, all
Java 3D threads inherited the priority from whatever the default was at the
time of creation.
Multitexture:
It's in 1.2 beta.
Doug Twilleager
Java 3D Team
Sun Microsystems
===========================================================================
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".
