> 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.
Correct
> 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.
I forgot that the range got reduced that much.
> But if you
> go over that, there could be distortion, because atoms near the left
> hand side will be overflowing their -2000 buffer limit.
Correct
> 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.
Correct on all points.
> 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.
Excellent investigative analysis!
> 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.
Actually, I would say that the Xyzd is causing more trouble than it is
worth. I added it relatively recently (1 year ago? 18 mos ago?).
At a minimum we can go back to storing the screen coordinates as 4 shorts.
That is an easy change that will increase the range and will not increase
memory consumption for macromolecules.
> 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.
If that is only going to give a zoom of 40 then clearly that is insufficient.
I think that we should just switch to ints ... perhaps retains the shorts
for X and Y.
> 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"
We should set up a time to dicuss this on the phone.
You will need to walk me through your previous email and help me digest it.
It seems to me that changing centers has a bigger impact on camera
position and perspective depth than you seem to think.
Miguel
-------------------------------------------------------
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&kid0944&bid$1720&dat1642
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
