Re: [gl4java-usergroup] OpenGL vs Java3D (was: Re: GL4Java FAQ]

[Kerry L. B. <ke...@vs...>]

Agreed.  Until recently I was a lead engine developer in the games
industry.  I got to sit in on a number of interesting Java related
conferences and round table discussions.  Once I got to meet the entire
Java3D team and ask them a number of hard questions.

It is my opinion that the Java3D team "does not get it".  They have "yet
another API", but it is what I would call an "academic" design.  By this I
do not just mean it misses most of the features most critical for game
developers (fast vertex access, fine grain texture control), the API is
unacceptably high-level without justification.  Once again, great for
spinning teapots and canned animation playback, but terrible for anything
interactive or closer to the "edge".

FWIW, I've been working on a cool project which now sits on top of gl4java,
here's a uber-brief explanation from a posting to another list a while back:

=====
We're from the games industry, with backgrounds in VR, distributed
processing and cryptographic protocols.  This project comes from 15+ years
of applied research, one example of was OnLive's Traveler (I was their 3D
guy, employee #4) which used a very small subset of this technology.

Our project is a massively multi-user VR system, highly scalable using a
network of normal PC's which self organize into "clusters" that provide a
fault tolerant, secure, and high speed distributed back end.  It includes
full duplex audio chat.  This gives us persistence, user custom content and
deformable objects, as well as other very cool things we won't talk about
yet. :)
=====

I've got tons of C++/Glide code that I'm porting into Java/OpenGL, and have
tons more to finish writing.  I've got a distributed scene graph, but I'm
trying damn hard to keep the individual objects from having to get tied to
that aspect of the architecture - I'm keeping interfaces clean so
components can be reused outside of the sg overhead.  It's worked so far,
one company is already using my texture code in their commercial flight sim
product.

The project will go open source when it hits beta, I'm competing against
teams at Sony and Microsoft for some multiplayer targets and I got tired of
them being the majority of hits to my web site, so access isn't unlimited
_yet_, but it will be.

I would be interested in collaborating and/or exchanging code (under
LGPL/BSD type terms, not GPL) on things over gl4java.  Objects I've got
running or almost running: CLOD terrain (patch based for dynamic loading,
deformable, fast terrain following), Quake2 and Quake3 avatars, a skydome
w/ time of day and atmospherics, starchart driven starfield.  Lots more on
the way.  Interested in (will work on next in any case) particle systems,
inverse kinematics and skeletal animations, an animation engine for 3DS/Max
tracks, and a mini-web browser that runs on texture arrays on world objects.

Kerry L. Bonin
Sr. Engineer, Security/Cryptography & Advanced Visualization, Cisco Systems.
VScape lead architect - Adaptive secure clustering for multiuser VR.

At 04:10 PM 4/13/00 +0200, Max Gilead wrote:
>Hi!
>
>Let me tell you the story...
>
>In deep past I was doing some programming in C++ (it was loong time ago...
when 386
>were good machines ;-)
>About a year ago I started to learn Java. In order to learn this from
practical
>side I decided to write a 3D modeler as a learning exercise (this
excercise is
>still not yet finished :-). After about three months I had to decide which
3D API
>to use. So, in that time I was a Java programmer almost totally without C/C++
>knowledge. First I tried Java3D because it was 'native' Java API. I read
some docs
>about it and was wondering why the hell it's so complicated? Then I
decided to try
>OpenGL. Whoa! That was it! OpenGL is simpler, faster to learn, easier to
use and
>easier to do what you really want to. Java3D is higher-level library that
simply
>does not fit my needs (editor). It's OK for displaying animations etc. but
when you
>need to fiddle with separate vertices and change them often, it's not a good
>solution.
>
>Java3D and OpenGL are not competing APIs. They're too different.
>
>And, in my humble opinion Java3D is not a good, clean API as OpenGL is. For
>example, take a look at its javax.vecmath package... say, you have a
Point3d point
>and Matrix3d matrix which is a rotation matrix and you want to rotate this
point
>using matrix. Obvious solution would be:
>point.rotate(matrix);
>but in Java3D you write:
>matrix.translate(point); - for me it's doing things backward.
>J3D's vecmath package doesn't have TONS of useful methods which I had to
write
>myself. Solution was simple: two weeks ago I sit down, removed
Java3D-compatible
>mathematical package from Fictor and wrote my own one - fast, simple and
flexible.
>
>You are right in one thing: using bare OpenGL as it is is sometimes
awkward in
>object environment, but it's a matter of simple wrapper class and one or two
>components and anyway one can get used to it :-) If you think about
writing such a
>wrapper class, I would be interested to cooperate. In fact, I have written
such a
>component but it's not finished yet.
>
>And - Java is whole lot better language than C++, not just slower... and
anybody
>should agree on it's mailing list :-)
>
>Bye,
>Max
>
>RICK ANDERSON wrote:
>
>> I question that I expected in the fact but which was missing from the
current
>> FAQ is the simple explanation of the relationship between GL4Java and
the Java3D
>> api.  Of particular interest would be the *why* part of the explanation.
>>
>> There's two approaches one could take, both of which assume that the actual
>> OpenGL calls would need to be mapped to native methods:
>>
>> 1) Map the current OpenGL calls as close as possible to Java
equivalents.  This
>> allows existing OpenGL developers to easily move to Java because it
leverages
>> their existing knowledge base.
>> 2) Implement the Java3D api and map the calls to the OpenGL equivalents.
 This
>> approach would probably be preferred by most "pure" Java developers as a
>> strategy which is more consistent with the Java philosophy of layering
its API's
>> on top of existing OS services.  In this case, the ultimate service
would be
>> provided by OpenGL, rather the the OS.
>>
>> Obviously GL4Java is using the first approach, but someone coming from
the Java
>> world would be interested in knowing the reasons this approach was used,
rather
>> then the second.  They would also be interested in knowing if you are
aware of
>> anyone doing the second approach.
>>
>> Personally, I find the choice to go this route to be somewhat confusing
since
>> it's primary beneficary is a C/C++ programmer.  Why would a C/C++
programmer
>> switch to doing the same thing, but slower?
>>
>> An interesting task would be to take these methods, and add the Java3D
api on
>> top of them.-- A. Rick
>
>--
>Max Gilead (gi...@li...) http://3d.linart.krakow.pl/OfficinaArtificialis
>-----------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>_______________________________________________
>gl4java-usergroup mailing list
>gl4...@li...
>http://lists.sourceforge.net/mailman/listinfo/gl4java-usergroup
>
>