Fiona Hunter wrote:
> As part of my applied computing degree, I have to do a research
> project on Java 3D to find out about:
Well, I might as well reply to everyone on the list. I'm hoping that my
comments might start a little discussion on what other people think are
good and bad features and things that need serious attention soon,
rather than what the Sun engineers think are good. A little public
discussion is always a good thing IMO.
> * what Java 3D does
Very simply: It provides an abstract API for creating 3D graphics. It is
abstract in that it gets away from being purely polygon based by
allowing you to create (nested) structures of objects as well as
associated elements like lighting, audio and external device
interaction.
It is only design to deal with 3D graphics. Anything 2D related is left
to other Java APIs like AWT, Swing and Java 2D.
> * what people think of it
Generally, it is OK. Not spectacular, but it has the right basis to be
good. Like most things from the Java camp at Sun, I think the APIs are
generally pretty good and well thought out, it is just the
implementation that is (sometimes very badly) executed. J3D falls into
the middle of this. The API is good but there is no way I would
recommend it as the API of choice to write a flight simulator in (in
fact we have several such projects running around internally for
prototyping and I have done just that - much to the amazement of others
in the company as they know how much I am involved in J3D).
IMHO, what needs to happen is have the developers running a much more
open list of outstanding bugs, bugs being fixed and fixed bugs not in
the current release. Also, the roll-out of updates needs to happen more
often. I spend a lot of time with JSDT and I really like the process
there. It gets fixes out to the community much faster and people feel as
though they are more involved in the real direction it takes.
Most problems, and questions being asked of this list, are related to
bugs in the implementation. A true Open Source license (not the SCSL)
would encourage many of these bugs to have been fixed _much_ quicker
than they have now. Also, having some decent
specifications/documentation wouldn't go astray either.
Where Java 3D is good, is that it is introducing a lot more people to 3D
graphics programming than OpenGL ever has. You can tell this from the
types of questions being asked of the list (pretty much the other half
of all questions asked, and what I deal with in the FAQ). Simply, Java3D
is much less scary to the newbie programmer than OpenGL and hence more
people are tempted to play with it. Simple things like dealing with
clipping issues and Z buffer resolution are examples of the newbie
questions that are very frequent here. This brings more people into 3D
graphics, which is a Good Thing for many reasons.
> * what applications Java 3D could have in both industry and
> academic research
Academic areas are quite good. However, in the large VE systems like
CAVEs there is still a lot of work to be done. Some of this is more due
to lacking features in the core Java spec (inability to deal with
multiple monitors simultaneously and lack of true full screen display
capabilities) that are hopefully being addressed in JDK 1.3. You can use
it to knock together a simple app pretty quickly. Much of this is due
more to the general productivity that Java as a whole gives you, rather
than just being J3D related by itself.
In industry, I think it is too early to really say. We've used it in
some serious, high paying applications and there are quite a few bad
areas (dealing with transparency the most notable problem area) that
need addressing ASAP. I think it would be find to build a CAD
application or simple game with, but, as I said before, high frame rate
applications like a simulator, it is not yet ready for due to lack of
hard realtime options to lock changes to the next frame being rendered
(due to the inherent multi-threaded nature of the design).
The most glaring problem with getting this accepted into a lot more
mainstream applications at the moment is the use of Video textures.
With consumer level cards starting to support direct video texturing
(taking a video stream and directly manipulating it like a static image
as a texture on an object) the demand for this capablity is very high.
VRML has had this since 1996. If you have a look back through the
archives over the last 6 months or so, there have been quite a few
questions about this (I've also received quite a few personal emails
asking for information about it too).
> * compare Java 3D with its opponents
I'm not sure if this is a real valid question as there really isn't that
much in the way of "Opponents" for J3D. There are many different 3D
graphics APIs that are designed for many different levels of
applications. Many are generated for a specific purpose. So, although
there might be a couple of hundred "3D Scene Graph APIs" available
(according to a panel at the last Siggraph) they don't really compete or
are opponents to J3D, which also has the same label. Perhaps the only
item that could be considered a direct "Opponent" would be the
Fahrenheit APIs from MS. Even then, because it is not yet available to
the general public, that is a non-issue too.
These are the areas I am most familiar with so I'll compare against my
general knowledge: VRML, PHIGS/PEX and OpenGL and to a somewhat lesser
extent Direct3D.
As a general rule, J3D fits in about the middle. The higher level
abstraction of J3D over PEX/OpenGL makes it simpler to quickly create an
application. However, due to this abstraction, you miss out on many of
the fundamental capabilities that you might want to have. J3D does not
provide you any mechanism for adding these directly. For example, if you
want to add multi-texturing support, it can't be done. Hence, you are
limited in aspects where you might want to use light/bump maps to doing
it yourself, rather than using underlying hardware (although I have seen
one example of environment mapping done in J3D)
On the other side of the coin, the level of abstraction provides some
very nice, clean interfaces for combining together many different
aspects. The behaviour model is generally quite good (quite a few noted
problems with the Alpha/Interpolator combination and the utility
questions) and the integration of sound and external devices I find
excellent. Some more work needs to be done, but the right approaches are
in place.
The level of abstraction, compared to VRML is quite good. VRML suffers
from having a vague event model that has caused quite serious problems
with interpretation over its lifetime. However, building general content
in VRML is much simpler, assuming you don't want to get too complex in
interaction (don't try to build a CAD program with VRML!). There are
some things that VRML is capable of that you cannot do in Java 3D (the
above mentioned video texturing is one example).
In reality, it is all horses-for-courses. VRML was designed for
enablinng content creation. OpenGL as a very minimal abstraction of the
video rendering hardware and PHIGS/Java 3D as something that exists in
between the two ends - but definitely aimed at a programmer, not an
artist.
The current failings of Java 3D is due to the implementation provided by
Sun. From following the list, and personal opinion, these are the most
deficient aspects of J3D:
- True 3D Audio rendering. J3D attempts to do everything in software and
never refers to the underlying audio hardware. If you have a CAVE
environment with a Lake DSP system, you won't use even 10% of its
capabilities. The same thing goes with many of the current consumer
space 3D audio cards. From what I understand, the code completely
ignores any of the current AudioDevice3D specific methods.
- Video Texturing/Multi Texturing. Already mentioned above, but a very
serious limitation for it being accepted in the games market.
- Alpha (transparency) handling. Badly broken at the moment. For
example, I can't create a line grid and then add in a textured object
with the texture containing transparency. It looks shocking!
- Multiple Screen support/Stereo support. The former is for the CAVE
people while the latter is for the PC crowd where HMDs and shutter
glasses are almost at commodity price points now (but definitely a much
requested feature in the sort of PC level applications that we develop).
- Faulty implementations of basic nodes (Shape3D, LOD, Billboard).
Memory leaks in Shape3D are a real problem. LOD and Billboard behaviours
are just wrong, being based on an elapsed frame count rather than if the
parent transform changes. The result is guaranteed 100% CPU usage as
soon as you put them in the scene graph.
- More simplistic way of adding input device/audio device support. While
the actual APIs for interfacing with these devices are excellent (IMHO),
the way of integrating them into the application is very poor. At the
moment you must make specific references to them in the code and compile
it in. If the app moves to a different machine that doesn't have exactly
the same hardware, your app won't run, or is faulty. A more generic
scheme of loading them is needed (I have intentions of writing something
along these lines, but haven't started yet).
--
Justin Couch Author, Java Hacker
Snr Software Engineer [EMAIL PROTECTED]
ADI Ltd, Systems Group http://www.vlc.com.au/~justin/
Java3D FAQ: http://tintoy.ncsa.uiuc.edu/~srp/java3d/faq.html
-------------------------------------------------------------------
"Look through the lens, and the light breaks down into many lights.
Turn it or move it, and a new set of arrangements appears... is it
a single light or many lights, lights that one must know how to
distinguish, recognise and appreciate? Is it one light with many
frames or one frame for many lights?" -Subcomandante Marcos
-------------------------------------------------------------------
===========================================================================
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".
