From: Max G. <gi...@li...> - 2000-04-13 14:17:55
|
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 ----------------------------------------------------------------------------- |