> 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.
It wasn't a dumb idea ... I just think it needed a slighly different
implementation.
>>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.
It is essentially the same thing that you wanted to do.
Atom can also extend from this.
That gives us a clean hierarchy of data structures for handling points
that have both real-world and screen coordinates.
> 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,
Correct regarding 'static'. We want each instance of this class to have
its own screenX,Y,Z.
'static' means 'global variable'
> and I guess final doesn't matter, because we
> aren't creating extensions of this to addtional subclasses. Is that
> right?
In fact, we *are* going to create additional subclasses. Atom is goint to
extend this class. That way, transformation operations can be applied
directly to atoms.
Think of the class instance member variables as a 'struct'. When you
extend a class you are just adding new variables to the end of the
'struct'. But all of the first members remain the same, so that operations
on the superclass keep working (generally).
> 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.
This will add 12 bytes per Point3f. (3 ints * 4 bytes/int).
The vast majority of points that we allocate are in Atoms. The space for
their screen coordinates is already allocated as members of Atom.
Because the Atom will actually *be* a Point3fi and a Point3f, we will
actually save some space ... we won't have to have a separate pointer to
the Point3f because the atom 'this' pointer will *be* a Point3f.
>>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;
OK :-)
>>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.
Q: Do you mean 'solved in bob200603' or 'solved in trunk' ?
> Tell me if you see something you
> don't like, but as far as I'm concerned, it's done.
My recollection is that at one point (before you were fired :-) you said
that you thought that perspectiveDepth could be handled in a better/more
elegant/simple way. I am wondering if you found this.
It has been a long time since I looked at the code ... either yours or
mine. That is why I am asking for guidance.
> Have you played with it on the bob200603 prototype and found it not
> working?
I have not looked at it. That is why I am asking.
> 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.
Right now I would rather not try to fix or change anything associated with
transforms.
Right now all I am trying to do is think through the implications of
introducing the following point hierarchy.
javax.vecmath.Point3f
org.jmol.vecmath.Point3fi
org.jmol.viewer.Atom
This is going to force some changes to the TransformManager, so I wanted
to know what the current status is from your perspective.
-------------------------------------------------------
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&kid0709&bid&3057&dat1642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
