Miguel wrote:
Bob,
In your work in Feb/Mar you were working on Polyhedra. At one point you
felt the need to introduce an 'Atom' that really wasn't an atom ... it was
just a point that needed to be transformed.
right. Dumb idea. you took care of that nicely with polyhedra.
We subsequently exchanged some emails where we said that it may be a good
idea to introduce an intermediate class.
I have thought about this some more, and I think that we should introduce
a class that extends Point3f by adding screen integer coordinates. I think
that this could simplify a lot of the code by eliminating the need for the
temporary Point3i variables. Memory consumption may go up slightly, but I
think it will be worth it. I think that working with the shapes would be
much easier.
I did a little local prototyping. I introduced a class called
org.jmol.vecmath.Point3fi:
public class Point3fi extends Point3f {
public int screenX;
public int screenY;
public int screenZ;
public void transform(Matrix4f matrix) {
screenX =
(int)(matrix.m00*x + matrix.m01*y + matrix.m02*z + matrix.m03);
screenY =
(int)(matrix.m10*x + matrix.m11*y + matrix.m12.z + matrix.m13);
screenZ =
(int)(matrix.m20*x + matrix.m21*y + matrix.m22.z + matrix.m23);
}
}
oh, now THAT's slick. Question: I'm still trying to figure out the place
for final and static. I see it's not static because it accesses the
instantiated screenX,Y,Z, and I guess final doesn't matter, because we
aren't creating extensions of this to addtional subclasses. Is that
right? I assume the compiler creates one copy of the function for any
instance of the class then? The only thing I would be concerned about is
even a little overhead for such a fundamental piece could be a memory
issue for someone.
The 'transform' method above does not deal with perspective depth.
So I 'page-faulted' and got distracted by that issue ...
You did a lot of work on the TransformManager. The particular issue that I
am interested in is 'perspectiveDepth'. I know that you put a lot of
thought into this, and I am wondering if you came up with any great
revelations regarding 'perspectiveDepth' and the camera location ...
Q: What is your current thinking on 'perspectiveDepth'?
very cool idea; nice appearance; impressively simple implementation;
pain in the butt; totally messes up surface rendering unless it is
PERFECTLY seamless;
messes with locations of surfaces and lines that are supposed to be
invariantly linear;
has to be turned off for proper viewing of crystals;
Q: Did you come up with a clean way to handle the camera position and
perspectiveDepth?
You fired me for that, remember? :)
This problem is solved in my opinion. Tell me if you see something you
don't like, but as far as I'm concerned, it's done.
Have you played with it on the bob200603 prototype and found it not
working? The following commands will be useful:
set windowcentered off
set picking center
then load 1crn.pdb, zoom WAY in, pick an atom close to the camera,
rotate 180 to bring the back end of the model into the camera. Then pick
that one and spin again. Iterate. Tell me when you break the camera.
The very slight jiggle that you see when you click the new atom is the
perspective lens focusing on that atom and distorting the bonds around
it. Very subtle. Not a bad effect, in my opinion, in that has a nice
confirming feel to it.
If you want to fix something, take a look at:
set picking rotate
then start clicking on atoms. There's a slight drift there that I can't
remember if I ever figured out. I guess not; it's still there.
Bob
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
