different position from commands typed vs. commands in script

[Elaine Meng]

My script rotamers.cxc does a bunch of stuff and then saves a position (view name p1) and then applies 4 repositioning commands (turn, turn, zoom, move). However, the result of executing the script is nothing like when you start with p1 (after script was run, command "view p1" to go back to that position) and then type in the 4 commands one by one. That is the desired position, whereas the position from just running this script is that you need to move the molecule downward (move y -4 or something like that, and maybe the rotation is a bit off too). I tried adding "wait" or "wait 1" after each command in the script but it doesn't help. I also tried making a shorter script without the rotamers but then I could not reproduce the problem. Maybe I'm doing something wrong, though.

Reassign as needed.

[Elaine Meng]

Although this is still all voodoo and chicken bones to me, I think it had to do with the "view" that was higher up in the script, even though it was before the position save "view name p1". By moving commands around and adding more "wait 1" I was able to make a new version of this script rot1.cxc that does not have this problem.

[Elaine Meng]

new script that doesn't have this weird inconsistency problem

[Eric Pettersen]

If you use "view matrix" after the script runs and compare it to commenting out the last 4 commands and running the script and then executing those 4 commands by hand and using "view matrix", the translation component of the camera matrix differs. I think T.G. would have to explain that -- I have no idea why that would be.

[Tom Goddard]

The problem is surely that the turn and zoom commands are using a different center of rotation in the script (even with wait 1) versus when run by hand one command at a time. Probably it has something to do with when the center of rotation is updated in front-center mode. Obviously not good, but I will have to investigate to say more.

[Tom Goddard]

Ok, I put in a "cofr" command before the 4 move commands at the end to see what it reports the center of rotation to be. Then I tried it without cofr and without the last 4 move commands and typed cofr by hand and got a different center of rotation. Why? It is pretty clear. The script hid atoms and swapped amino acids so the center of the bounding box was changed. But the scene was never redrawn and so when you do the 4 move commands in the script it is not using the update center of rotation after you changed what is displayed. If I just put in a wait 1 before your 4 move commands it all works because the center of rotation gets updated. In fact, none of the wait 1 after your move commands are needed. It is just this wait 1 before the commands so that the center of rotation gets computed from the new molecule bounds.

Seems pretty cryptic. Why doesn't the center of rotation get updated for the change in displayed atoms if the scene is never drawn before your first move command? A look at the code reveals the following. If the scene is drawn and the geometry has changed (e.g. atoms hidden) then the center of rotation will be updated. But merely hiding or showing some atoms does not immediately update the center of rotation. Why not? The code just is not smart enough. There is no way for the current code to ask "Has the scene changed since the last time the center of rotation was updated?" when say the turn command asks it what is the current center of rotation. Only the rendering code determines if the scene has changed and that is why a frame has to be drawn to decide if the center of rotation needs updating. So why not always assume the center of rotation needs updating? Because it is very time consuming to always recompute the bounding box from all the atoms when almost always it has not changed at all. So it is a performance issue.

[Tom Goddard]

So in summary. The current code only updates the center of rotation if the scene is drawn. So a script has to do this tricky thing and put a "wait 1" before commands that depend on the center of rotation such as the turn or zoom command. I agree that is pretty horrible. But the code simply has no current mechanism to know whether the scene geometry has changed (e.g. atoms hidden) other than during a redraw, and it does not want to simply recompute the center of rotation every time it is needed because that will be very slow when larger structures are shown.

So I don't have any good solution for this. But it has been this way for 6 years and this is the first report of the problem. So it is probably limited to a very rare use. In this case it was trying to copy hand typed movement commands into a script. This is an excruciating way to set the view, so it is not too surprising that no one has reported this before.

[Tom Goddard]

Since I see not tractable solution to this and it seems a very rare problem I am inclined to call it a "limitation".

Maybe a documentation page on scripting could list pitfalls and describe some of the weird cases we know of where obscure uses of "wait 1" are needed to get a script to behave the same as hand typed commands.

If we had such a summary of all the "wait 1" script weirdness, maybe that would inspire some general solution where script execution could use different rules than currently, to alleviate these problems. In Chimera the solution was that a frame is rendered after every command. This makes scripts run slow, and in fact I wonder if it would work at all in no-gui mode where no rendering actually happens. So I am not inclined to revert to the Chimera behavior, especially since the movie recording behavior then becomes entirely different requiring movie scripters to know other occult thing, like when to use semi-colons.