> Hi Miguel, > Initially I was thinking about Java3D myself. Some time ago I played a > bit with it. > I certainly am not an expert on 3D stuff. To be honest I didn�t find it > particularly easy to work with but I think the reason for this was I > didn�t find a good �introduction to Java3D programming� on the net. I have never used it. But my introduction to 3D only started 5 months ago when I started implementing the Jmol 3D engine.
> Secondly I had the impression that the development is not exactly a > priority for Sun so I was not sure if it was such a good idea to use it > for our project. I agree, it doesn't seem like much of a priority for them. Nevertheless, I think they will continue to support it. > I thought also that it might be hard to find > programmers with some experience in Java3D. True. But OpenGL programmers will quickly adapt. And there are books available. > > I think that Java losing mindshare and going "out of fashion" is a > more legitimate concern. > > What do you mean by this exactly? It was late at night ... maybe I shouldn't have said that :-) > Are there any *signs* to support this? No. I think that initial enthusiasm has waned somewhat. But enthusiasm in general has waned as the hi-tech economy plunged into the toilet. > I had the impression that Java is a settled *thing* in business > application development. It probably is ... I'm sure it is. > Are there any alternatives at the moment? Surely not C#? No alternatives ... agreed ... not C# > I will give you some more points to consider first. > > 1. The molecular modelling stuff will be done in stages. There are > different levels of modelling possible. Ab-initio is the best but also > the most CPU intensive. In fact you need a supercomputer or a cluster of > very big computers to handle at most 100 atoms or so but in the end you > are sure you know just about anything there is to know about your > molecule. There are other approaches to do modelling based on > semi-empirical and empirical algorithms, which are (a lot) less, > accurate but can handle from thousands until millions of atoms depending > on the algorithm. > We would like to incorporate some of the less CPU intensive algorithms > in our CAMD tool. VASP (or another) would be used separate from our tool > and is, as you said, for a multiprocessor environment. That is why I > mentioned that the CAMD tool needs to be able to show the result of the > simulation. That, but only that! > In fact we would prefer that anybody with a reasonable recent computer > (2+ GHz) is able to use our CAMD tool. The same holds for the DC client. You will not be deploying for a couple of years. At that point 2Ghz is going to be awfully slow. Nevertheless, I see your point about the amount of CPU involved to do modeling calculations on the fly. > 2. [EMAIL PROTECTED] (the first Distributed Computing (DC) project) has been > developing a general purpose DC environment called BOINC. It is meant as > a platform for all DC projects. People will be able to switch between > projects without the need to load another DC screensaver. They will also > be able to participate at several DC projects at the same time. The > software is written in C++. > Although it is not used anywhere at the moment ([EMAIL PROTECTED] will start > with the distribution for their project soon) most people in our project > want to use it. I am almost the only one who is opposing it. Some are > doubting but tend to agree with the majority. If they really have a platform then using it is a very attractive idea. > I am opposing it because I think most make the mistake in thinking that > �Joe average� is interested in participating in more than one DC > project. I do not think this is the case. No doubt there *are* people > that are interested in being able to switch but those are not the > *average* kind of people. > I think that *betting on one horse* is not the right way to proceed. > There are other projects interested in BOINC but they already have their > own DC environment so for them it is only an additional path to other > spare CPU cycles. (You can use both environments in parallel on the > server side). I haven't heard about a new DC project that *only* wants > to use BOINC (except ours that is). Well, I don't see it as 'betting on one horse'. The Seti people have more experience at this than anyone else. I assume they can build a platform that will work. Go with their platform, with the explicit plan to revisit the decision in 12 months. The team will learn a lot from using it. In 12 months you will be able to better evaluate it. Attempt to isolate your code from their code by wrapping a layer around it. If you decide to write the majority of your application in Java, then just communicate with their code via a socket. > 3. From the start I was sure we had to add native libraries if we wanted > to use Java. (It is time consuming to develop molecular modelling > software even the ones using empirical algorithms). But I thought it > would not pose a problem using the JNI package. Do you have any > experience with this? No experience with JNI. But I would use sockets rather than JNI. If you use JNI then you are making a significant commitment to the library that you are trying to use. > Actually I do not understand why most DC projects do *not* use Java. To > me it seems the most logical choice as Java (Sun) is mainly focused on > business application (database access and stuff) and I am sure Java is > optimised for this kind of applications. I agree with you > > I believe that C++ has an advantage over Java in the area of OpenGL > support, but you are not currently thinking of using OpenGL. > > Actually I have been thinking about it. One of the reasons I thought > about Java3D in the first place. > Am I incorrect in thinking that Java3D uses OpenGL? Yes, I think so. > > I am not a fan of Java3D ... as a broad market product. Nevertheless > it does work (I assume) and it does have its place. And I think its > place is for applications like yours. Java3D will slowly gain broader > support and acceptance over the coming years. > > Why didn�t you use it for Jmol? Jmol is explicitly targeted at academia and general web deployment. We want people to build public web sites and for anyone to be able to see renderings of molecules. I know some people at a university. They are in the process of setting up some Linux machines for biochemistry. Their *new* hand-me-down machines are 350Mhz and 128Mb ram. > Was it a personal thing maybe? We want wide deployment of Jmol as *the* web-based molecular viewer. So we want it to run on everything. > Why do you think it *has* a future at all? Because, I don't think they have any choice. OpenGL is a standard. Java will continue to exist. Java must work with OpenGL. > Sun doesn�t seem to promote > it very much and they don�t seem to work on it (not much anyway). I have > been thinking about contacting the Java3D developers team about it but > I haven�t yet. Maybe I should! I think you should. Miguel > > > Regards, > > Val�re > > > > > > > ------------------------------------------------------- > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo > The Event For Linux Datacenter Solutions & Strategies in The Enterprise > Linux in the Boardroom; in the Front Office; & in the Server Room > http://www.enterpriselinuxforum.com > _______________________________________________ > Jmol-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jmol-developers -------------------------------------------------- Miguel Howard [EMAIL PROTECTED] c/Pe�a Primera 11-13 esc dcha 6B 37002 Salamanca Espa�a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US = home 011 34 923 27 10 82 12:00 noon Eastern US = cell 011 34 650 52 54 58 6:00 pm Spain -------------------------------------------------- ------------------------------------------------------- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
