Just checked in, Jmol 11.1.21 will test a new translucency option. I
still have to check all the shapes, but basically the way it works is
that you specify "translucent n" instead of "translucent", where n can
be 0 to 3.
color atoms translucent 1
isosurface variable charge translucent 2
isosurface plane {1 1 1 0} translucent 3 yellow
The higher the number, the weaker the image -- the more translucent the
object. This new translucency model uses "standard" translucent color
additivity -- translucent objects both "emit" their color and "blend" in
with the objects behind them so as to change those objects' color.
Obscured objects can be translucent themselves. The model supports up to
two translucent objects in front of an opaque one. If THREE translucent
objects are in line, then the rear two translucent objects -- the two
being "hidden" by the front one -- are not guaranteed to appear in the
correct color-order. (You will see both, but you will not see when one
goes behind the other.)
Right now I have "translucent 1" being the default -- the same as
"translucent" by itself, and a relatively strong image. Jmol 10-type
translucency is "translucent 0", and you can change the default
translucency with
set defaultTranslucent [0 - 3]
So if you don't like this at all, use
set defaultTranslucent 0
and you will have what you have always had.
The effect with halos (I think) is outstanding. The effect with
spacefill and wireframe is intriguing though probably not particularly
valuable. The effect with cartoons, especially with hermiteLevel=5 is
something to behold. The effect with rockets is very cool --- you see
interior dividers, one per amino acid residue.
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
