>> - I worked out most of the design for a z-buffer scheme that >> (I believe) would work quite well for molecular viewing. > > Can you email how it works? Yes I will. But it will probably be about three weeks before I can get to it. This weekend is Carnaval. And Thursday I leave on a 2 week trip.
I hope to do some prototyping with my laptop while on the trip. > >> - I also worked out a more complicated scheme which would offer >> significantly better performance >> * rendering times would be cut by 25%-50% >> * at a cost of significantly more complex code > > As long as the algorithm is very well described, and the code > is written is good as possible (variable names, method names etc) I > see no problem there... First I will try to get the "simple" version up and running. If/when things are stable then we can take a stab at the "complicated" scheme. That way we can also compare with the "simple" version and confirm that a) it is actually faster, and b) that the speedup is worth the trouble. > A so called space filling rendering is indeed 'missing' at this > time... I would put higher priority on isosurfaces though... Per my other email, the isosurfaces scare me a bit; I don't know anything about them. Can you point me to an URL which can give me a "simple" explanation? Do you know anybody who has implemented a renderer, even using OpenGL? >> For example, is it important to render "charge fields" correctly for >> the things you are doing? > > If you mean charge fields rendered as isosurface.... Yes, that is what I meant. I just didn't know they were called isosurfaces when I wrote this email :) >> 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? > > No, *if* I had money, I would have you spend your time on integrating > Jmol work CDK, i.e. having it use a common rendering API, the CDK core > classes, port the IO to CDK, etc... Well, everything I am doing is volunteer work, so money is not the determining factor. So, since you can't convince me to work on these things with money, you probably should do the following: - "encourage" me to work on things - give me a lot of leeway/flexibility to work on subsystems independently - give me feedback (positive or negative) on the stuff I build, so that at least I will know that somebone is using it - keep me from getting frustrated :) > And yes, a port of the scripting engine... I would just love to have a > scripting mode in JChemPaint You said "port of the scripting engine". Porting the existing engine with RasMol/Chime syntax would be easy, but I'm not sure that is what you want. This sounds like a better candidate for the "new & improved" scripting language. But I'll keep this scripting idea in mind while I am looking at the JChemPaint code. > *If* the work *had* to be in the area of having Jmol substitute > Rasmol/Chime , I would have you work on display of cartoons of > enzymes, backbond, helices, sheet etc... OK My main motivation for the RasMol/Chime substitute is that this was my reason for getting involved in Jmol. So I am reluctant to give up on it. But if I can't find somebody else who is interested in promoting its use then I may have to put it on the shelf. 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
