OK, I see the limitation on zoom.
The same issue relates to distortion.
Here's the issue:
Xyzd:
We are packing all x,y,z values into too small a number of bits.
* 6 5 4 3 2 1 0
* 3210987654321098765432109876543210987654321098765432109876543210
* !o------d-------!o------z-------!o------y-------!o------x-------
*
* ! is the "guard bit"; o is the "overflow bit"
*
* Note that the capacity for each is 0x3fff, (2^14)-1 = 16383
* which, because of the zero offset of 2000, becomes -2000 to 14383.
*
The problem with this is that we are storing SCREEN COORDINATES in this
structure.
Put aside perspectiveDepth for a minute. Even with a little 300x300
applet window there is a problem. You can zoom in about 25x ("zoom
2500") and still have xy values in the -2000 to 14383 range. But if you
go over that, there could be distortion, because atoms near the left
hand side will be overflowing their -2000 buffer limit.
Now take a large applet window, perhaps 800x800. Now "zoom 1100" hits
the xy limit. The reason this has not been noticed is that those atoms
are not on screen. BUT the problem will be severe if we have lines and
planes and pmesh and such. In those cases, if one end of the object is
pinned at -2000 and the other is on screen, what happens is that the
line or plane is put in the wrong position.
But the real problem is in the z direction. Because of the way this is
set up, all z values are turned into positive numbers ("in front of the
camera"). And in addition to that, the minimum value for z in Atom.java
is further restricted to 100. So the real range for z is 100 - 14383.
OK, now you have an 800x800 applet. Easily you can have a z range of 0 -
800 for a simple globular protein. The max zoom is about 18x before
distortion in the z direction sets in.
SO, my analysis is that the problem is this:
There is too much of a restriction in Xyzd.
I like Xyzd; I suspect that really is one of the secrets to the fast
rendering.
So I'd propose:
a) in Atom.java, remove the z limitations.
b) in Xyzd.java, remove the two "guard/overflow" bits. They are NEVER
checked.
c) in Xyzd.java, remove the zero offset -- just store the int values
directly.
This then allows a range of -2^15+1 to 2^15-1 -- -32767 to 32767. For an
800x800 applet, that will allow a zoom of 40, roughly.
I may play around with this some if I have time.
ABOUT THE ROBOTIC ARM
the more I think about this, the more I'm worried that it just
introduces a different complex difficult situation. Miguel, before we go
there, let's consider everything we want to be able to do, then consider
which part of this can be part of a transformation matrix, and which
part has to be done at the transformPoint() stage (zoom and perspective,
I think).
The practical problem as I see it is this:
The user has one frame of reference only -- the model. That's THE
coordinate system for the user. Now, that means that when the user
changes centers, that will be described in the user's coordinate system
-- "rotate about this molecular axis" "rotate about x centered on this atom"
And, we still have the xyz buffer problem.
Bob
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
