From: <val...@pi...> - 2003-10-17 17:08:16
|
Hi Miguel, > It would be helpful for me to understand what type of potential > applications you are thinking of ... > > Are you thinking of Jmol for viewing molecules? Yes. We want to develop a kind of CAD tool for designing our own=20 molecules from the bottom up. We call it a Computer Aided Molecular=20 Design tool. We also want to use it to display results of molecular=20 modelling packages, which ones are unknown at the moment but we are=20 thinking about VASP? We also want to develop our own scripting language=20 (probably in Python using Jython). Secondly, we would like to use it for a Distributed Computing client=20 (screensaver). Our website is at www.nanoathome.org. > Or, are you thinking of the using the graphics engine for rendering ot= her > types of objects? It depends on what you mean by "other types of objects". > Whatever you are thinking of using, is it in the context of an applet = or > of a standalone application? Standalone application. >> I would be grateful Miguel if you could give me more details about th= is >> new 3D engine you are working on. It would help me defending our >> possible co-operation to the other critical project members. > >You said 'defending' ... what else are you looking at? Nothing at the moment! I have to defend my proposition of using Java=20 instead of some other language to develop our software. There are others=20 in our group who would prefer to do it in C or C++. We want our software to run on Windows and Linux systems at least. Speed=20 is in fact the only factor that works against using Java for our project=20 but I think looking at the demo of your new engine that we should go for=20 it. There are just too many benefits in using Java. Jmol is also, I think, one of the better examples of a =91general=92=20 molecular visualisation package. Not too specific, not too big so it=20 should be fairly easy to strip it from the parts we will not need for=20 our software. Did you test Jmol on a Linux or other unix system? Are you developing with the latest J2SE release (1.4.2_01)? I have noticed a considerable improvement in speed compared to 1.4. > But it would be good to have someone else take a critical look at it, = or > to use it heavily. We will do that! Not to worry! :-) Regards, Val=E8re |
From: Miguel <mt...@mt...> - 2003-10-18 15:39:20
|
>> It would be helpful for me to understand what type of potential >> applications you are thinking of ... >> >> Are you thinking of Jmol for viewing molecules? > Yes. We want to develop a kind of CAD tool for designing our own > molecules from the bottom up. Hmmm ... interesting ... > We call it a Computer Aided Molecular Design tool. Sounds like it is more important that you look at CDK than at Jmol. > We also want to use it to display results of molecular > modelling packages, which ones are unknown at the moment but we are > thinking about VASP? I don't know anything about this kind of thing. > We also want to develop our own scripting > language (probably in Python using Jython). Very good. You will need to build some powerful tools. >> is it in the context of an applet or of a standalone application? > Standalone application. OK >>> I would be grateful Miguel if you could give me more details about >>> this new 3D engine you are working on. It would help me defending our= >>> possible co-operation to the other critical project members. >> >>You said 'defending' ... what else are you looking at? > > Nothing at the moment=21 I have to defend my proposition of using Java > instead of some other language to develop our software. There are > others > in our group who would prefer to do it in C or C++. > We want our software to run on Windows and Linux systems at least. > Speed > is in fact the only factor that works against using Java for our > project but I think looking at the demo of your new engine that we > should go for it. Runtime speed is *not* a factor. I think I may have said this in my previous email ... I think that for th= e level of your application, Java code is only 10-20% slower. You are not writing systems code. Tell one of your developers to take a few days, write some benchmarks, an= d test it for himself/herself. Java will be slightly slower, but not enough= to really matter. What matters for your project is developer productivity. I think that you= r developers will be more productive using Java, especially your best developers. Java *will* be slower if the developers are wasteful in generating lots o= f garbage at runtime. But those same developers would have cost you more *development time* in the C++ world. I think that Java losing mindshare and going =22out of fashion=22 is a mo= re legitimate concern. See additional comments below. > There are just too many benefits in using Java. > Jmol is also, I think, one of the better examples of a =91general=92 > molecular visualisation package. Not too specific, not too big so it > should be fairly easy to strip it from the parts we will not need for > our software. > Did you test Jmol on a Linux or other unix system? Most of my development is done on RedHat Linux. When I am traveling I do development on a Win32 laptop. Egon uses a Sun. > Are you developing with the latest J2SE release (1.4.2_01)? Yes > I have noticed a considerable improvement in speed compared to 1.4. It is good to hear that you think it is faster. Sun PR said that it was faster. The specific graphics operations I want are still too slow. (I said that the graphics operations are slow, not that Java is inherently slow.) >> But it would be good to have someone else take a critical look at it, > or to use it heavily. > We will do that=21 Not to worry=21 :-) Good. Now, for my random thoughts. In fact, my blunt advice: I spent many years programming in C and C++ ... I have been programming i= n Java for 11 months. Frankly, I would not dream of doing your project in C++. You want to be cross-platform, Win + *nix. Which offers a more portable cross-platform *environment* of systems calls? You want to build a complicated CAD system. This is not a low-end system,= it is a high-end system. Your target users will have good hardware, multiple CPUs. You will want to use those CPUs to check the validity of structures in real-time. Which offers a more portable way of managing threads, Java or C++? You want to do some distributed computed ... in the form if your screen saver. Which language is better suited for managing distributed processes= ? Something *very* important for you should be availability of molecular modeling libraries. I honestly have no idea whether Java or C++ has bette= r stuff. But this is *much* more important than measly performance considerations. I believe that C++ has an advantage over Java in the area of OpenGL support, but you are not currently thinking of using OpenGL. Finally, I am going to going to say something that may surprise you. I don't think you should use Jmol ... you should use Java3D (or OpenGL if= you choose the C++ path). You are building a complex system that is targeted at users who will be running on high-end hardware. And we are talking about high-end hardware when you start to deplay 2 or 3 years from now. Your target users will *absolutely* have 3D graphics hardware. You should use it. 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. Training ... I am sure that you are hoping to have a team of developers. If you use Java3D/OpenGL then it will be much easier to train your developers and get them up to speed. Jmol is small and attractive and a more complete package for rendering molecules. But I think your project will outgrow it quickly. In summary, if it was my project - I would decide which chemical modeling libray to use. If there was a clear winner in the C++ world that may sway me to use C++ - I would use Java over C++ - I would use Java3D or OpenGL instead of jmol Let me know what you think. Don't hold back ... I didn't :-) Miguel > > Regards, > > Val=E8re > > > > > > ------------------------------------------------------- > 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 > Jmol-developers=40lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jmol-developers -------------------------------------------------- Miguel Howard miguel=40howards.org c/Pe=F1a Primera 11-13 esc dcha 6B 37002 Salamanca Espa=F1a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US =3D home 011 34 923 27 10 82 12:00 noon Eastern US =3D cell 011 34 650 52 54 58 6:00 pm Spain -------------------------------------------------- |
From: <val...@pi...> - 2003-10-18 15:38:27
|
Hi Miguel, > Let me know what you think. > Don't hold back ... I didn't On the contrary I appreciate your honest opinion. Initially I was thinking about Java3D myself. Some time ago I played a=20 bit with it. I certainly am not an expert on 3D stuff. To be honest I didn=92t find it= =20 particularly easy to work with but I think the reason for this was I=20 didn=92t find a good =93introduction to Java3D programming=94 on the net. Secondly I had the impression that the development is not exactly a=20 priority for Sun so I was not sure if it was such a good idea to use it=20 for our project. I thought also that it might be hard to find=20 programmers with some experience in Java3D. > I think that Java losing mindshare and going "out of fashion" is a mor= e > legitimate concern. What do you mean by this exactly? Are there any *signs* to support this? I had the impression that Java is a settled *thing* in business=20 application development. Are there any alternatives at the moment? Surely not C#? >>I have noticed a considerable improvement in speed compared to 1.4. > It is good to hear that you think it is faster. Sun PR said that it wa= s > faster. The specific graphics operations I want are still too slow. (I > said that the graphics operations are slow, not that Java is inherentl= y > slow.) I didn=92t do any benchmarking on it but the software I am working on=20 showed a considerably improvement on start-up time which actually was a=20 pleasant surprise. > Now, for my random thoughts. In fact, my blunt advice: I will give you some more points to consider first. 1. The molecular modelling stuff will be done in stages. There are=20 different levels of modelling possible. Ab-initio is the best but also=20 the most CPU intensive. In fact you need a supercomputer or a cluster of=20 very big computers to handle at most 100 atoms or so but in the end you=20 are sure you know just about anything there is to know about your=20 molecule. There are other approaches to do modelling based on=20 semi-empirical and empirical algorithms, which are (a lot) less,=20 accurate but can handle from thousands until millions of atoms depending=20 on the algorithm. We would like to incorporate some of the less CPU intensive algorithms=20 in our CAMD tool. VASP (or another) would be used separate from our tool=20 and is, as you said, for a multiprocessor environment. That is why I=20 mentioned that the CAMD tool needs to be able to show the result of the=20 simulation. That, but only that! In fact we would prefer that anybody with a reasonable recent computer=20 (2+ GHz) is able to use our CAMD tool. The same holds for the DC client. 2. Seti@Home (the first Distributed Computing (DC) project) has been=20 developing a general purpose DC environment called BOINC. It is meant as=20 a platform for all DC projects. People will be able to switch between=20 projects without the need to load another DC screensaver. They will also=20 be able to participate at several DC projects at the same time. The=20 software is written in C++. Although it is not used anywhere at the moment (seti@home will start=20 with the distribution for their project soon) most people in our project=20 want to use it. I am almost the only one who is opposing it. Some are=20 doubting but tend to agree with the majority. I am opposing it because I think most make the mistake in thinking that=20 =93Joe average=94 is interested in participating in more than one DC=20 project. I do not think this is the case. No doubt there *are* people=20 that are interested in being able to switch but those are not the=20 *average* kind of people. I think that *betting on one horse* is not the right way to proceed.=20 There are other projects interested in BOINC but they already have their=20 own DC environment so for them it is only an additional path to other=20 spare CPU cycles. (You can use both environments in parallel on the=20 server side). I haven't heard about a new DC project that *only* wants=20 to use BOINC (except ours that is). 3. From the start I was sure we had to add native libraries if we wanted=20 to use Java. (It is time consuming to develop molecular modelling=20 software even the ones using empirical algorithms). But I thought it=20 would not pose a problem using the JNI package. Do you have any=20 experience with this? Actually I do not understand why most DC projects do *not* use Java. To=20 me it seems the most logical choice as Java (Sun) is mainly focused on=20 business application (database access and stuff) and I am sure Java is=20 optimised for this kind of applications. > 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=20 about Java3D in the first place. Am I incorrect in thinking that Java3D uses OpenGL? > I am not a fan of Java3D ... as a broad market product. Nevertheless i= t > 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 a= nd > acceptance over the coming years. Why didn=92t you use it for Jmol? Was it a personal thing maybe? Why do you think it *has* a future at all? Sun doesn=92t seem to promote=20 it very much and they don=92t seem to work on it (not much anyway). I hav= e=20 been thinking about contacting the Java3D developers team about it but I=20 haven=92t yet. Maybe I should! Regards, Val=E8re |
From: Miguel <mt...@mt...> - 2003-10-18 17:01:09
|
> 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=92t find = it > particularly easy to work with but I think the reason for this was I > didn=92t find a good =93introduction to Java3D programming=94 on the ne= t. 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 =22out of fashion=22 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=23? No alternatives ... agreed ... not C=23 > 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 o= f > very big computers to handle at most 100 atoms or so but in the end yo= u > 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 dependin= g > 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 too= l > 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=21 > 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. Seti=40Home (the first Distributed Computing (DC) project) has been > developing a general purpose DC environment called BOINC. It is meant a= s > a platform for all DC projects. People will be able to switch between > projects without the need to load another DC screensaver. They will als= o > 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 (seti=40home will start > with the distribution for their project soon) most people in our projec= t > 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= > =93Joe average=94 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 thei= r > 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 wante= d > 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=92t 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 w= e 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=92t seem to promote > it very much and they don=92t seem to work on it (not much anyway). I h= ave > been thinking about contacting the Java3D developers team about it but= > I haven=92t yet. Maybe I should=21 I think you should. Miguel > > > Regards, > > Val=E8re > > > > > > > ------------------------------------------------------- > This SF.net email sponsored by: Enterprise Linux Forum Conference & Exp= o > 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 > Jmol-developers=40lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jmol-developers -------------------------------------------------- Miguel Howard miguel=40howards.org c/Pe=F1a Primera 11-13 esc dcha 6B 37002 Salamanca Espa=F1a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US =3D home 011 34 923 27 10 82 12:00 noon Eastern US =3D cell 011 34 650 52 54 58 6:00 pm Spain -------------------------------------------------- |
From: E.L. W. (Egon) <eg...@sc...> - 2003-10-19 13:28:43
|
On Saturday 18 October 2003 12:23, Val=E8re Swinnen wrote: > > Let me know what you think. > > Don't hold back ... I didn't > > On the contrary I appreciate your honest opinion. > > 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=92t find = it > particularly easy to work with but I think the reason for this was I > didn=92t find a good =93introduction to Java3D programming=94 on the ne= t. > 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 thought also that it might be hard to find > programmers with some experience in Java3D. Combine that with: - a few weeks ago Sun announced to be supporting a OpenGL based Java3D replacement - Java3D implementations are known to be *very* buggy (which is probably the reason why there are so few people using it) > > I think that Java losing mindshare and going "out of fashion" is a m= ore > > legitimate concern. > > What do you mean by this exactly? Are there any *signs* to support this= ? > I had the impression that Java is a settled *thing* in business > application development. > Are there any alternatives at the moment? Surely not C#? > > >>I have noticed a considerable improvement in speed compared to 1.4. > > > > It is good to hear that you think it is faster. Sun PR said that it = was > > faster. The specific graphics operations I want are still too slow. = (I > > said that the graphics operations are slow, not that Java is inheren= tly > > slow.) > > I didn=92t do any benchmarking on it but the software I am working on > showed a considerably improvement on start-up time which actually was a > pleasant surprise. > > > Now, for my random thoughts. In fact, my blunt advice: > > 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 o= f > 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 dependin= g > 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 too= l > 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! Toda, I've been working on porting the VASP reader to CDK (cdk.sf.net) which is the chemical library the Jmol uses... Will upload this tomorrow. > 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. > > 2. Seti@Home (the first Distributed Computing (DC) project) has been > developing a general purpose DC environment called BOINC. It is meant a= s > a platform for all DC projects. People will be able to switch between > projects without the need to load another DC screensaver. They will als= o > 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 (seti@home will start > with the distribution for their project soon) most people in our projec= t > want to use it. I am almost the only one who is opposing it. Some are > doubting but tend to agree with the majority. > I am opposing it because I think most make the mistake in thinking that > =93Joe average=94 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 thei= r > 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). > > 3. From the start I was sure we had to add native libraries if we wante= d > 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? Not directly... but have a look at JOElib (joelib.sf.net) which is a GPL-= ed=20 Java chemical library... they use JNI to link with the Ghemical libraries= (in=20 C++) to do basic quantum mechanics... > 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 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? Don't remember... > > 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 pla= ce > > is for applications like yours. Java3D will slowly gain broader supp= ort > > and acceptance over the coming years. > > Why didn=92t you use it for Jmol? Was it a personal thing maybe? No, due to the many Java3D bugs in the implementation *and* that the plug= in is=20 not available for all browsers/platforms makes it very unportable... > Why do you think it *has* a future at all? Sun doesn=92t seem to promot= e > it very much and they don=92t seem to work on it (not much anyway). I h= ave > been thinking about contacting the Java3D developers team about it but = I > haven=92t yet. Maybe I should! See above... look for the press announcement... I really don't think Java= 3D=20 has any future... And seriously... I think Miguel's engine is more than what we could wish = for=20 from Java3D... Egon --=20 PhD Molecular Representation in Chemometrics Laboratory of Analytical Chemistry http://www-cac.sci.kun.nl/people/egonw.html |
From: Peter Murray-R. <pm...@ca...> - 2003-10-19 14:07:27
|
At 12:23 18/10/2003 +0200, =?windows-1252?Q?Val=E8re_Swinnen?= wrote: >Hi Miguel, > > > Let me know what you think. > > Don't hold back ... I didn't > >On the contrary I appreciate your honest opinion. > >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. >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 thought also that it might be hard to find programmers >with some experience in Java3D. We had an excursion into molecular display using Java3D about 2 years ago. It gave sufficient trouble that we decided to drop it. The following comments may be outofdate but concerned us: - it didn't seem to be particularly fast. - it had bad interactions with Swing. In particular the frame for display would overlap menu items, etc. - it required a specific *.dll for windows. This made it almost impossible to distribute since we would have to field all the problems of installation. For these reasons we decided to go with Jmol. The current version seems excellent. Peter |
From: Miguel <mt...@mt...> - 2003-10-19 15:59:34
|
> We had an excursion into molecular display using Java3D about 2 years > ago. It gave sufficient trouble that we decided to drop it. The > following comments may be outofdate but concerned us: > - it didn't seem to be particularly fast. > - it had bad interactions with Swing. In particular the frame for > display would overlap menu items, etc. > - it required a specific *.dll for windows. This made it almost > impossible to distribute since we would have to field all the problems > of installation. Peter, Thanks for your comments. As I believe I said in one of my messages, I have no experience with either OpenGL or with Java3D. My basic point to Valere was this. They are trying to design a high-end CAD system. Therefore, they are targeting people with high-end hardware. Since OpenGL seems to be the standard 3D graphics package, then I would go with OpenGL. Therefore, if it was my project, I would pursue Java3D as the Java API on top of OpenGL. Now, Egon just sent something about Sun supporting some 'alternate' OpenGL solution for Java. Valere should certainly investigate this. > For these reasons we decided to go with Jmol. The current version seems > excellent. I am glad that you like it. And I am relatively pleased with the performance. Nevertheless, if I was doing a 'professional' product instead of a 'mass-market' product I think that I would look for something that used 3D graphics hardware. (Maybe not. If you have a fast CPU then the jmol.viewer.Graphics3D package will (no doubt) run quite well). Miguel |
From: Miguel <mt...@mt...> - 2003-10-19 19:29:26
|
> Q about the trace... does it consist of small tubes... because I would > not expect the snake like appearence... it seems a bit roundish... In what sense do you mean 'roundish'? I intentionally made it round so that the helices in the proteins would b= e 'well-rounded'. But, perhaps I went too far. > And, about the FAQ you made... it looked ok this morning... what is > wrong with it? I wanted to do two things: 1. Have another outline level, to break it up into 'chapters' 2. Make the font that is used for the individual sections smaller. Miguel > > Egon > > -- > PhD Molecular Representation in Chemometrics > Laboratory of Analytical Chemistry > http://www-cac.sci.kun.nl/people/egonw.html -------------------------------------------------- Miguel Howard miguel=40howards.org c/Pe=F1a Primera 11-13 esc dcha 6B 37002 Salamanca Espa=F1a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US =3D home 011 34 923 27 10 82 12:00 noon Eastern US =3D cell 011 34 650 52 54 58 6:00 pm Spain -------------------------------------------------- |
From: E.L. W. (Egon) <eg...@sc...> - 2003-10-19 20:06:50
|
On Sunday 19 October 2003 16:19, Miguel wrote: > Now, Egon just sent something about Sun supporting some 'alternate' OpenGL > solution for Java. Valere should certainly investigate this. I've tried to find the announcement, and below is a list of related links: http://www.j3d.org/ -> "27 July The final two developers working on Java3D have been sacked by Sun. That means there is no official support coming from them, and obviously no further development. At this point Java3D is effectively dead, unless the various community efforts can convince Sun to release all or part of the source. We're keeping track of the various efforts with replacement scene graphs and also expect to see further announcements from us too with respect to where the site is going in the future." There seems to be an interesting FAQ there too, but it did not work on the Konq I had...: http://www.j3d.org/faq/index.html Took me some time... 20 minutes... but I found the article again... turned out to be much older than I thought... July 28... http://www.internetnews.com/dev-news/article.php/2241281 Anyway, seems that they are going to replace Java3D with a OpenGL based java 3D engine... deal together with SGI. But, it will probably be at least a year before we can expect a release... or maybe not. Egon -- PhD Molecular Representation in Chemometrics Laboratory of Analytical Chemistry http://www-cac.sci.kun.nl/people/egonw.html |
From: Miguel <mt...@mt...> - 2003-10-19 21:34:54
|
> -> "27 July The final two developers working on Java3D have been sacked > by Sun. That means there is no official support coming from them, and > obviously no further development. At this point Java3D is effectively > dead Well, so much for my statement that Sun 'has to support it' Miguel |
From: E.L. W. (Egon) <eg...@sc...> - 2003-10-19 20:56:03
|
On Sunday 19 October 2003 21:28, Miguel wrote: > > Q about the trace... does it consist of small tubes... because I would > > not expect the snake like appearence... it seems a bit roundish... > > In what sense do you mean 'roundish'? The strange shadowing effects... > I intentionally made it round so that the helices in the proteins would be > 'well-rounded'. But, perhaps I went too far. Not sure... looks like a snake now, but with tubes of this size it should be fine... possibly, you could have it indeed rounded but in a spline way again... i.e. the have the gradient of the edges of two rounded rubes next to each other to be the same... > > And, about the FAQ you made... it looked ok this morning... what is > > wrong with it? > > I wanted to do two things: > 1. Have another outline level, to break it up into 'chapters' > 2. Make the font that is used for the individual sections smaller. Ok, I'll have a look at it... Egon -- PhD Molecular Representation in Chemometrics Laboratory of Analytical Chemistry http://www-cac.sci.kun.nl/people/egonw.html |
From: Miguel <mt...@mt...> - 2003-10-20 01:41:32
|
>> In what sense do you mean 'roundish'? > > The strange shadowing effects... By 'strange effects' I think you mean the *bumps* on the surface. That is a side-effect of the way that I am drawing the trace. I agree that it is undesirable. However, I spent most of a day trying to get rid of them and was unsuccessful. Therefore, I decided to quit working on it and keep thinking about it until someone comes up with a better idea of how to render it. Miguel |
From: E.L. W. (Egon) <eg...@sc...> - 2003-10-19 21:34:07
|
On Sunday 19 October 2003 22:24, Miguel wrote: > >> In what sense do you mean 'roundish'? > > > > The strange shadowing effects... > > By 'strange effects' I think you mean the *bumps* on the surface. Indeed. > That is a side-effect of the way that I am drawing the trace. I agree that > it is undesirable. However, I spent most of a day trying to get rid of > them and was unsuccessful. Therefore, I decided to quit working on it and > keep thinking about it until someone comes up with a better idea of how to > render it. Right ;) It looks fine as it is... just wanted to understand why it looked this way ;) Egon -- PhD Molecular Representation in Chemometrics Laboratory of Analytical Chemistry http://www-cac.sci.kun.nl/people/egonw.html |
From: Miguel <mt...@mt...> - 2003-10-20 01:41:32
|
>> That is a side-effect of the way that I am drawing the trace. I agree >> that it is undesirable. However, I spent most of a day trying to get >> rid of them and was unsuccessful. Therefore, I decided to quit working >> on it and keep thinking about it until someone comes up with a better >> idea of how to render it. > > Right ;) It looks fine as it is... just wanted to understand why it > looked this way ;) The trace is drawn as follows: - calculate the hermite spline curve - at each pixel on the curve, draw a complete sphere So, the effect you see is caused by the 'spheres'. Whichever sphere gets drawn first 'claims' the pixel. So that the colors of the pixels are not really correct. RasMol (Chime) actually draws bonds this way ... calculate the points for a line ... at each point on the line draw a sphere. I think what is needed is an 'accumulation buffer' to do a better job of smoothing out the colors. If two or more colors hit the same pixel (from adjacent spheres) then average them out. But, as I said, I feel like I've wasted too much time on this for now. Miguel |
From: <val...@pi...> - 2003-10-20 20:37:21
|
Hi, >>We are using as prototypes the models developed by Merkle and Drexler >>that are posted as PDB files at IMM.org. >> =20 >> Egon. We have contacted IMM concerning those pdb files. They are=20 public domain so there is no problem if you want to add them as examples=20 to the Jmol distribution. The license issues concerned the images of=20 those files that are presented on the IMM website, not the pdb files=20 themselves. >I put up a small demo for you: > http://jmol.sf.net/demo/nanotech > > =20 > Thanks a lot. I appreciate it. >Should work from most browsers. (If you find one that does *not* >work, please let me know.) > >I put a few buttons on there just to demonstrate a few things. They >basically allow you to see the composition of the 'machines' by selectin= g >specific atom types. > >Give me some examples of more interesting 'views' and I will be glad to = add >additional buttons. > =20 > I liked the first series of buttons better. The ones were you could=20 select which type of atoms were displayed. >> "27 July The final two developers working on Java3D have been sacked >> by Sun. That means there is no official support coming from them, and >> obviously no further development. At this point Java3D is effectively >> dead >Well, so much for my statement that Sun 'has to support it' I think we can safely forget Java3D as an option for our project. Thanks again for looking it up Egon. I couldn't find it on the Sun websi= te. I have found another possible solution JOGL (https://jogl.dev.java.net/)=20 Java bindings for OpenGL. I am not sure yet if it is mature enough for our purposes though. I am thinking maybe we should use the Jmol engine first and replace it=20 at a later date with something like JOGL or the result of this Sun SGI=20 deal (if any). It is rather crucial we have a 3D engine asap because=20 the development of other parts of our project heavily depend on it. Regards, Val=E8re |
From: Miguel <mt...@mt...> - 2003-10-20 20:46:19
|
> I liked the first series of buttons better. The ones were you could > select which type of atoms were displayed. The current set of buttons should be a superset of what you had previously ... what's missing? Miguel |
From: E.L. W. (Egon) <eg...@sc...> - 2003-10-18 12:21:10
|
On Friday 17 October 2003 19:09, Val=E8re Swinnen wrote: > Did you test Jmol on a Linux or other unix system? I am using a Debian testing system, using Sun'd 1.4.2_01 J2SDK... Blackdown's does not run on testing at this moment. > Are you developing with the latest J2SE release (1.4.2_01)? > I have noticed a considerable improvement in speed compared to 1.4. Egon --=20 PhD Molecular Representation in Chemometrics Laboratory of Analytical Chemistry http://www-cac.sci.kun.nl/people/egonw.html |