Fiona,
I agree with many of the points that Justin has raised. The only thing I'd
like to add is that I feel that the Java 3D team are spreading themselves
too thin. The Java 3D API contains support for many "peripheral"
technologies (sound, HMD, input devices, etc.) that I feel are detracting
from the stability of the core API.
I'd be happier with a phased roll-out where the core renderer was stabilized
and issues addressed, then behaviors, and then start adding
bells-and-whistles features. My suspicion is that the Java 3D marketing
people feel that the API has to win some kind of feature-list comparison
with every other 3D API under the sun (no pun intended).
If the core was stabile and allowed OpenGL like functionality there would be
much more scope for 3rd-party developers to code there own "extensions" or
add application specific behavior.
Let's face it, a stabile, cross-platform, well supported, Java wrapper for
OpenGL is a mighty achievement in its own right!
Personally I quite like the structure of the API. I'm just worried that Sun
are biting off more than they can chew with J3D version 1.2. I agree that
most of the features in Java 3D are required at some point, but as we have
seen, features such as collision detection are not practically useful in the
API at present. Coding the collision detection *must* have detracted from
other (more important) areas of the API that still need lots of development
effort.
As Justin said, more openness from Sun would go a long way... We are the
target audience for the API, why don't they ask the J3D community to
prioritize fixes and feature additions?
Sincerely,
Daniel Selman
[EMAIL PROTECTED]
http://www.tornadolabs.com
> -----Original Message-----
> From: Discussion list for Java 3D API
> [mailto:[EMAIL PROTECTED]]On Behalf Of Justin Couch
> Sent: 10 November 1999 01:54
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA3D] Request for information
>
>
> 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".
>
===========================================================================
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".
