|
From: RICK A. <RIC...@sl...> - 2000-04-13 18:13:25
|
>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. I can easily believe this. There are several of the Sun-Java teams that seem to have the NIH syndrome bigtime. The Java collection folks come to mind as an example of extreme hubris. JGL wasn't good enough, so they re-invented it (poorly) from scratch. At the same time, they decided that the official java collections should also be exempt from following the JavaBean naming conventions defined by their own company???? The best way to deal with that kind of arrogance is simply ignore them until they go away. This provides a great deal of clarity and makes the approach taken by gl4java make a lot more sense. It also gets back to my original point, I assumed that the folks who did GL4Java had a reason for the decision/approach that was made. In my case, I guessed wrong on the reason. Either way, I'd suggest capturing, IN THE FAQ, the essence of the reason for putting a thin layer on top of OpenGL as opposed to using the Java3D API. There are d*mn good reasons for the choice and it makes sense to capture them. >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: > >Our project is a massively multi-user VR system, highly scalable using a >network of normal PC's which self organize into "clusters" Are you the guys who presented "How to keep 10,000 online gamers happy" last year at JavaOne? There was an awful lot of "then a miracle happens and we won't tell you how" in that presentation :-) > I've got tons of C++/Glide code that I'm porting into Java/OpenGL .. > The project will go open source when it hits beta Sounds very cool! >Kerry L. Bonin >>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 >> |