>> - It is ridiculous to require Java3D. >> * It severely limits the user-base. >> * I'm not a member of the "graphics community", but it doesn't >> seem to me that it has very much momentum. > > I agree - it has left me with a deep opposition to Java3D. Among other > things it requires reinstalling with new Java versions. OK
>> - We need a solution that supports 3D as an >> applet with an old browser JVM. > Yes Good. I think the browser applet is the key to extending the user-base ... not the power-user base, but the end-user base. >> - I worked out most of the design for a z-buffer scheme that >> (I believe) would work quite well for molecular viewing. >> ... > For proteins and large crystals performance may matter, but for small > molecules no problem. I am happy to go with this solution Agreed. For small molecules performance generally isn't a problem. My "5x slower" estimate was intended to be very conservative (i.e. pessimistic). I *hope* it isn't that bad. > It would be valuable in that it will get more converts, but not > essential in that there would be no users. Sorry, I don't understand what you are trying to say. > The grfx community has several different types of user: > - modellers > - displayers > - printers > (For example many people will model a protein in O, view it in Protein > Modeller and publish it with Molscript or POVRAY). Don't try to > emulate everything!) OK. Is the current povray output from jmol of "publishing quality"? I know that it has some limitatations - no double-bond support - none of the protein stuff: strands, ribbons, stars, curly-Qs, doo-dads :) How important is that stuff? What percentage of "the chemistry community" (whatever that means) wants/needs it? >>For the work that *you* are doing, is true 3D rendering important? > > No. But I am rather spartan in my approach. I am happy with current > Jmol. But when I want to impress people then the high quality matters > :-) What is missing from jmol+povray that falls short when you want to impress? >>Or is the pseudo-3D rendering of Jmol good enough? > > I think so. I would certainly not try to emulate lighting models. At this point I agree. I don't feel any need to work on the fine details of luminosity and specular hilites. (Frankly, most of it is over my head anyway :) > There is a lot of science that is more important No doubt that is true. But I am only a pseudo-scientist ... a computer scientist. Therefore, about all I can hope to do help create some better tools for the scientific scientists :) >>For example, is it important to render "charge fields" correctly for >> the things you are doing? > > Yes. But we have a basic problem in that we do not have a good charge > field model. Is this a 3D array of vectors or an object with a convex > hull, etc. Sorry, can't help. I think I have seen electromagnetic fields rendered as smoothed "blankets of snow" (convex hulls?) with gradient colors. Are you saying that there is not a standard way that people think about the shapes of these fields? >>If *you* had some "skilled talent" to allocate for a month or two, is >> this the area where you would choose spend it? >> >>If not, what would *you* have me work on? > > Wow! Actually I would concentrate on displaying molecular and atomic > properties at intermediate graphics resolution (e.g. charges, dipoles, > electron density, etc.) Explain in more detail please. > I would also want an interactive (event) GUI. Do you mean that you want drive the gui with program-generated events? How does this differ from scripting? >>It seems to me that this is the last major piece that we need to start >> to make Jmol an acceptable RasMol/Chime substitute. Clearly it would >> take a lot more polishing, but all the pieces would be there. What >> other pieces are missing? > > Scripting. We have discussed this earlier. OK. I need some help understanding what aspect of scripting needs to be extended. With the exception of "protein-specific visualization stuff", jmol now supports *all* rasmol script commands. (no doubt there are bugs, but the interpreter is solid). Yes, the (inherited) RasMol syntax is not very modern. (I am about to demonstrate how little I understand about the problem space :) But, what is missing from the underlying functionality? >>Do *you* have any interest in a RasMol/Chime substitute? > > A great deal. I would like to see Jmol provide an open source approach > to some/all of the CHIME functionality. To date, I have been working from the RasMol doc and haven't spent more than a couple of hours looking at Chime. I need some specific examples of things that Chime can do that are missing from Jmol. You don't need to send me a long list. Just send me one or two pointers that I can follow. > If I had such a tool I could > pass CML objects to it. This could include animation either from > implicit semantics (vibrations) or explicit - dynamics or reactions So, are the things you want/need animation/vibration/resonance things (that aren't in RasMol)? >>Let me know what you think. > > You must be brave to ask for a shopping list! brave? ... or stupid! :) Miguel ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
