Jmol developers. Correction -- bug found in Triangle renderer -- no more stray lines. Planes are clean; isosurfaces are smooth. Please thank Jeff Tseng and Miguel Howard for working with me on this. That last bug was a doozy. VERY TRICKY!!! In any case, it's fixed now, and we have some pretty nice translucency. We do see some digital banding/interference (sp?) effects when the back side of a surface interacts with the front side, but I'm not certain exactly where that is coming from. This is removed if slabbing is on, and we could add an option that removes the back parts of isosurfaces, but it's so neat with them there that at least for now I don't want to remove it. Hey, this is the first time we've seen the BACK side of any translucent object!
You have to check out the halos. Truly ethereal. Comments and suggestions appreciated. Bob 11.1.21 Introduces "real" color translucency color xxxx translucent N where N is 0 to 3. translucent 0 same as Jmol 10.2 translucent 1 1/2 translucency (default) translucent 2 3/4 translucency translucent 3 7/8 translucency (very sheer) Bob Hanson wrote: > The effect for planes and isosurfaces is, as we say in Minnesota, > "interesting." Some will like it; some won't. The effect is that you > see a hint of a "mesh" included even if you do not ask for one. Now, > the reason this is "interesting" is that in some ways is really nice > -- I personally think you get a much better sense of the curvature of > a surface and the angle of a plane, but others may feel it detracts. > But it's not perfectly smooth. > > This is experimental. The design is such that if you use translucency > 1-3, then the amount of memory allocated to construct the image is > doubled, but if you have no translucent objects, then there is no > additional memory allocated, and there may even be some efficiencies > introduced because I cleaned up some of the methods. > > Comments appreciated once this gets released. > > > > > > > > > > Halos are > Wait till you see halos!!! Ooooh. And just for kicks, I made the Jmol > frank translucent 1. > > If we wanted to, then, we could specify > > color translucency n > > For example: > > > > Miguel wrote: > >>> sorry. Forgot to build; had an extra semicolon. >>> >> >> >> no problem ... pulling down now >> >> >> >>> OK, here is the situation: >>> >>> I think this translucency is going to work. It has a great feel to it, >>> and with two translucent objects it is >>> excellent. It seems to suffer -- or have the feature -- of >>> showing the triangles a bit -- sort of a bright line around each >>> triangle. My analysis is that >>> it is due to multiple writes to the pbuffer along a given line. >>> >> >> >> I think that you are exactly right. When two triangles come together the >> edges get written twice. I was trying to ensure that there was no >> 'cracking' that occurred in solid surfaces. In the opaque world it >> did not >> make any difference ... The story wasy "better safe than sorry". >> >> >> >>> Unless >>> we have a way around that, >>> you get a brightening due to the multiple layering. >>> >> >> >> You may already be doing this in the code, but here is an idea. >> >> If the pixel is translucent *and* its ARGB value == the current tbuf >> (translucent buffer) ARGB value, then drop the pixel ... don't mix it >> with >> the pbuf >> >> As I write this I am thinking that this problem may start to show up in >> other places. >> >> >> >>> So: >>> >>> 1) This is a cool feature and we should keep it, or >>> 2) We need to get rid of it. >>> 3) We introduce it this way anyway and try to fix it later. >>> >>> I'm stuck on this one. Miguel, maybe you have an idea what is going on. >>> >> >> >> As I said, I think that you are right. >> >> I know that there were places where I was explicitly drawing more than >> once. When two triangles were being drawn side-by-side there were times >> when a pixel or two between them would not get filled in. This >> fence-condition "cracking" is always a problem in the graphics world, >> especially if you are doing everything in integers ... as we are. (An >> interesting historical note, the original 1984 Macintosh graphics system >> placed the coordinates *between* the pixels instead of *on* the >> pixels in >> order to minimize/avoid this problem. They probably still have this >> model.) >> >> Not sure what the solution is, other than to discard duplicate pixels. >> Even so, I suspect that there will still be some problems because there >> will be cases where the z-depth value will be off by 1. >> >> >> I'll take a look at the build. >> >> Q: What easy script can I run that best shows the problem? >> >> >> Miguel >> >> > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
