Pim, pim schravendijk wrote:
>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... > > isosurface,pmesh, polyhedra, lcaocartoons,molecular orbitals -- all triangles with associated normals. dots -- just little spheres, I think. stars -- just little tubes, I suppose. halos -- little dots, all in a plane. Or maybe translucent filled disks trickier -- trace, cartoons, strands, etc. These will need some special care. Each of these will need a generator that extends its associated reader. Some readers will need slight tweaks to minimize the code needed in a generator. > > >>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. > > > Exactly. I do know, and the way it's done is to first sort all the layers, then deliver them. No way we have that memory in Jmol. So that is a BIG bonus for using Jmol as a "front end" for PovRay. True translucency. Jmol just does the top three layers correctly, then it's hit and miss. Turns out that's mostly what people need. Not many people turn objects like bonds and atoms translucent, as you have done in your test. Those are "worst case" because there is such a likelihood there will be many layers. Cartoons, isosurfaces -- they appear much more correctly. >>>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? > > Very simple in Jmol: viewer.createImage(fileName,stringData,Integer.MAX_VALUE) >Related to that, the old PovraySaver class had IOexception handlers at >every writing step. I guess those are not necessary anymore? > > > I wouldn't think so. >>># 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 :) > > > If you can make tubes with spherical ends only at one end, that is the way to do it. That's what Jmol does. >>># 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... > > > I don't think I implemented dashed lines. You will need to do that. flat endcaps on those. >>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 ! :) > > > too bad for you. ;) Seriously, just ignore that. Use 0.0 - 1.0. The reason for the others is just some people may be more familiar with 0-255 or need to use that for some reason, and the 0-8 lets me be sure I'm getting a particular level, mostly for when I was testing. But 0.0 - 1.0 is the reliable one. That should always work. You've done a lot. May I have a patch so I can see what you've got and make comments/suggestions mainly regarding efficiency or coding styles? Bob -- Robert M. Hanson Professor of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 ------------------------------------------------------------------------- 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
