Re: [Jmol-users] Synchronizing distributed molecular models

[Miguel H. <mt...@mt...>]

> No, no, no: Not in the context of a web page at all. This is for
> real, live, one-on-one tutoring, or, alternatively, for group
> teaching / group discussion over the Net.

OK

> Currently I am just displaying the JmolApplet in a Window that
> is managed by my distributed presentation system. This is because
> I already have an "applet loader" that can (basically) load *any*
> applet (including the JmolApplet) in a distributed fashion - that is, if
> it is loaded from the file system of one participant, my distributed
> presentation system sees to it that it gets loaded *locally* from
> the machines of *all* other participants as well. (Applet parameters are
> taken from a simple Java properties file, so I do not even
> have to *parse* anything at all...)

Sounds very useful ... and very cool!

>    Jmol would be a "verrry nice to have" add-on to my existing
> distributed presentation system. Even just synchronizing the
> *loading* of the *same* molecular model, without further
> synchronizing its state upon interactive modification by the
> participants, is already a good thing to have - though proper
> synchronization of the whole state of that model, over the
> whole duration my presentation, would be even better -
> so much better in fact that I can *hardly* resist the temptation
> to get it: hence my questions...

That's fine. I think we can get what you want.

>> Have you played with Jmol source code and built the example .java
>> viewer application?
>
> No, not yet. I am somewhat shy about getting too close
> to "someone else's" source code ;-) In particular, I *much*
> prefer to stick to a solution that does *not* involve (incompatible)
> changes to existing code. I also prefer *not* to make use of
> knowledge that is not part of an official interface if I can help
> it.

I suppose I misspoke when I said "Jmol source code".

There is a sample Java application that you can compile which loads Jmol
into a simple window. It is called examples/Integration.java

*If* you get to the point that you want/need to use your own Java
application (or your own applet), then you can start building your app
from there ... without touching the Jmol source code.

> (Such sins will likely come back to haunt me, my experience
> tells me.)

We have all had such nightmares :-)

>     But I will now have a closer look at the Jmol source code.
> I just felt that someone who already knows Jmol well, as
> you certainly do, could stop me *early* from starting to
> run in a wrong or unusually difficult direction...
>
>> Are the distributed copies all displaying the exact image?
>
> Yes, that's the idea. We are discussing some chemistry problem,
> and, in that context, are looking at a molecular model - and
> perhaps manipulating it. It's like a virtual classroom, you see
> (but no video please! - we cannot afford the network bandwith:
> we want most of that for our *audio* links). If we don't see all the
> *exact* same presentation, we will find it very difficult to
> communicate clearly and succinctly...
>
>> If so, then the easiest thing will be to blit the entire image around
>> ... that may not be what you are looking for ... because it would turn
>> this into a rather trivial project :-)
>
> There is something to that.
> ...
>     However: (1) application sharing is limited to Windows-
> Windows cooperation, which is already A Bad Thing in itself.

Actually, I was thinking along slightly different lines.

Start with Integration.java
capture the rgb images as they get rendered.
We will call this your 'image server'

Then, write a small Java applet/application that runs on the client
machines. And broadcast images to them from your 'image server'.


> (2) As to the blitting approach more generally: some of my pupils
> are connected to the Net via relatively slow dialup-lines.
> Since we also want good audio-links, blitting too many raster
> images too often does not seem such a wonderful thing to do.

Agreed. Moving images in appropriate across a WAN with dial-up users.


>   If, instead of blitting many images, I just distribute the essentials
> of new viewing information (like scale, view direction, translation,
> etc. which amounts to a few doubles at worst) after one of
> the participants has finished(!) resizing, rotating, or moving a
> shared 3D model, and if I "interpolate" between the recipient's
> current model state and the new (stable) state received over the
> Net, modifying the local 3D model in "slow motion" from current
> state to new state, I can get away with *orders*of*magnitude*
> fewer bytes transmitted in the process - and still have very nice,
> intuitive behavior of the model: (almost) no transmission or image
> update delays, no image stuttering, no bad image quality: but the
> "real thing" for each and every participant...
Correct.


>   I am well aware that the "market" for my admittedly more difficult
> approach to synchronizing the display of molecular models may
> go away in the near future: namely, as soon as transfer speed over the
> Net improves by at least an order of magnitude for *all* of my pupils.
> But I want to do a first-rate tutoring job right *now*: so here is my
> problem, and hence my need for your educated guess
> as regards the difficulty of what I am hoping to achieve with Jmol
> (whether semi-independent Jmol applet, or completely embedded
> Jmol "plugin" for my scripted presentation documents).

I don't think it will be too hard to do.

I can provide you with calls which give you the state of the display.
Through a combination of JmolStatusListener enhancements and additional
methods to inquire about the state of the transformations.

(A note regarding rotations and zooms. I think that it would be very
difficult to calculate and send 'deltas' to the current x, y, and z
rotations. Instead, we will send the entire rotation matrix every time.)


The more I think about this the more I am beginning to think that we
should consider embedding this functionality into the base JmolApplet. I
don't think it would add too much overhead, and it would allow others to
use your distributed teaching method.

Let's keep talking.


Miguel