On 9/29/07, Bob Hanson <[EMAIL PROTECTED]> wrote: > This is terrific. Pim, I am so glad you are doing this. Can't wait to > see cartoons and hermite paths and such....
Most of these things are triangulated surfaces in Jmol, I guess? Then it shouldn't be too difficult (I'm optimistic here :) What else is there? (Iso)surfaces, dotted surfaces, meshes... > this is true for Jmol as well, by the way. The difference is that Jmol > only properly treats three layers (one opaque and two translucent). When > there are more than that, you get some improper rendering of the > surfaces more than two layers back. I can imagine transparency is a difficult feature. I'm not sure how povray manages to get the deeper layers nice, probably in a way too computationally intensive for an interactive application. > >What should be the standard, rgbf or rgbt? > beats me. How do they look with different translucent levels? I'll make samples. > > >New points: > > > ># jmol now writes an .ini file with in it just some basic povray stuff > >in it. It is not necessary, but good practice to do this, it should be > >done :) What is the best way to write a call to do this? > > > is this a file that PovRay reads, then? Yes, povray reads it. It is just the command line options combined, but you don't want to have to remember these, so it's good they are in a file :) I suggest the povrayExporter header or footer method should have a call to write this data into a text file. Are there sturdy standard methods to open/create a file for writing? Related to that, the old PovraySaver class had IOexception handlers at every writing step. I guess those are not necessary anymore? > ># Historically the PovraySaver put balls at both the ends of a bond. > >If I activate that for renderCylinder I have the side effect that for > >a bond between two different elements two balls of both colors are > >put in the middle (invisible if bonds are opaque). I would like to add > >a (private?) renderPoint method that can render ... points that are > >not of type atom. Is that ok? > > > There's no reason the balls should be there in the middle of the bond. > That's a bug. They should be flat end points. Let me take a look at the > generic stick rendering. It is not the exporter class doing this, it is not even in the jmol code, I just took it from the previous povray macro. The idea to have these balls was to have a nicely jointed chain of bonds when you turn the rendering of the atoms off in povray. I think I will just remove it completely, one can have a nicely jointed chain when putting the atom radius the same size as the bond radius in Jmol, and you can just output that directly. Creative people can always add things later on if they really want to :) > ># For double bonds, PovraySaver had a rather ingenious scheme! Shall I > >translate that to the Exporter class, or else: where can I find the > >scheme Jmol uses in the viewer? > > > It's in SticksRenderer.java. It's pretty good. But don't I already have > it properly sending the multiple bonds data to the exporter? I think so. > There should be no reason to change this. The Sticks renderer is already > doing that calculation so that you see in PovRay what you see in Jmol. Didn't try that out yet. Will test it out, will also test the hydrogen bonds... > Ignore most of that. It all gets translated to 0-255 in the end. The > "official" scale is 0 to 1 as fractions 0.1, 0.2, etc. Don't use the > 0,2,3,4,5,6,7,8 business -- that's really just fluff.The real scale is 0 > to 1. There are methods to give you that already in the exporter, or > Graphics3D, I think. It's true, there are only really 8 levels, but that > isn't terribly important. In the future there could be many more; I just > implemented that many as a starting point. It seems sufficient. So use > 0.0 - 1.0 exclusively. Yes, I use the internal levels, so it always works fine. My problem is more that I don't like the many confusing ways there are to change the levels via the script interface ! :) -- Greetings, Pim http://www.molmod.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
