I concur with most of what Justin and Dan are saying. I especially
agree with Uwe and Martic that Java 3D is not ready for commercial
prime time until the install and GC situation improves considerably.
I would like take one exception to what Justin had to say about the
behavior model being a good one in Java 3D. Having done a lot of 3D
UI work in VRML-Java and now Java 3D, I'd say that VRML was definitely
ahead of the power curve, both in concept and design, when it came to
addressing UI problems in 3D and event driven problems in general.
Don't get me wrong, there are some real problems with doing serious
application development with VRML-java that don't exist with Java
3D-Java, but i just don't see where the behavior model in Java 3D is
significantly better than the one in VRML -- at least from the slice
of the pie that I'm working with. In fact, I'd say that for designing
applications that are heavy into event handling and processing, such
as UIs doing lots of in-scene manipulation, the VRML event routing
model was far superior because it was so explicit and
straightforward. The problem with VRML was not with it, but with
having to surface through the EAI or submerge into script nodes to get
the heavy lifting done. And, at least for Cosmo, the event model
pretty much all worked as advertised, and it worked synchronously with
the rendering side, which can't be said of Java 3D (at least from what
I've seen so far -- please correct me if I am wrong).
I see such fundamental matters as event handling, rendering
synchronization, and even multiple displays as being part of the core
(at least my version of the core) that Dan is refering to. I too
would like to see efforts for cleanup/improvement focused on
establishing a sound backbone for 3D development, with the
embellishments and the more application specific stuff coming later or
being added by open source development.
--jon
> Date: Wed, 10 Nov 1999 14:17:22 -0000
> From: Daniel Selman <[EMAIL PROTECTED]>
> Subject: Re: Request for information
>
> 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
>
--
____________________ Peculiar Technologies ____________________
Jon Barrilleaux 3800 Lake Shore Ave. Purveyors of
[EMAIL PROTECTED] Oakland, CA 94610 Alternate Reality
510.444.4370 voc Augmented Simulation
510.444.0231 fax www.augsim.com and 3D Solutions
===========================================================================
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".
