Re: [XMakemol-discuss] Manual adjustment of bounding box

[Matt Hodges]

>>>>> Wolfram Quester writes:

 > > I'll have a look at these. (I fixed the one you didn't tackle.)

 > Ok, thats great. Some of them survived however after I applied your
 > patch to a clean 5.12 tree. But this doesn't matter here.

I think these changes are simple enough. I'll have a quick look, and
commit them to CVS soon.

 > > It also doesn't work for translations.

 > What do you mean with translations? Is there a feature I didn't
 > notice or do you mean the track center/original position items? I
 > thought I had tested the last and it worked here...

I mean translations using Control with Mouse-1 and Mouse-2 (see
"Help->Mouse").

 > > Doesn't the existing code do something like this anyway? The
 > > bounding box is eight vectors in the local axis frame, and these
 > > are then transformed into the fixed axis frame. Would it be
 > > easier if your dialog just represented differences from the
 > > default values?

 > Hm, this is what your patch does, if I understand it correctly. But
 > let me explain how we want to use the bounding box: We are doing
 > Monte-Carlo simulations. We have a simulation box which is repeated
 > in all space directions periodically. The bounding-box shall
 > represent our simulation box. As an input to our simulations we
 > have the density, from which the coordinates of the box are
 > calculated. So for us the absolute coordinates are easily accssible
 > and we can write them to an output file. So normally the
 > coordinates are known in advance. But in cases they are not, and we
 > enter them later we don't know the difference to the coordinates of
 > an automatically calculated bounding box. So I'd prefer the
 > possibility to enter absolute coordinates in the dialog. Next, the
 > automatic bbox considers only visible atoms but sometimes I want to
 > follow the movement of only one atom through the box.

OK. I can see the value in both types of behaviour.

 > To get this we could do the following:
 > 1. directly after loading the file calculate the bbox over all
 > atoms and store the result in an additional variable
 > 2. if values for the bounding box are read from the file or entered
 > in the dialog we calculate the differences to the additional
 > variables and use them as bbox_by_hand.
 > 3. To allow the "follow one atom" thing an option could be
 > introduced in the dialog to let him choose if all atoms or only the
 > visible ones should be bounded.

Yes, we can certainly have per-frame bounding box data, and a variable
keeping track of what type of data, if any, has been read in. In this
case, also having a dialog makes things more complicated, and I'm not
sure this extra complexity would be worthwhile.

 > > Can you try the attached patch? Have a look at the changes
 > > relative to what you sent, and see if they make sense. I think it
 > > now works as expected (i.e., for any translations/rotations).

 > I did! And your way of doing the trick is much more elegant than my
 > approach. However I'd like to have the possiblity to enter absolute
 > coordinates. I'd try to implement my suggestions above. To me they
 > seem a bit clumsy, but not that difficult to implement.

You should be able to use the same logic. Present the numbers in the
dialog with the values of the min/max coordinates added, and subtract
these when reading them back. That is, always deal with the
*differences* internally.

 > There is another thing in your patch I like very much: The shaded
 > walls of the bbox. But we should separate the two patches since the
 > shading is ready for release, while the box is far away from it.

This is now more similar to the non-GL rendering. I thought of a very
simple way to do it for the GL code, and I've already committed it to
CVS.

 > > Agreed. I would also like the possibility of the bounding box
 > > being specified by an origin and three cell vectors that are not
 > > necessarily orthogonal. Some discussion is needed here.

 > Oh yes. Even if I don't have immediate use of this feature I can
 > think of many applications. It would be really nice.

While it would be nice, lack of this feature is no reason to delay
inclusion of other things that work well.

 > > I think it is fixed.

 > Yes, but let me await your response to the above mentioned things
 > ;-)

In summary, I think that:

(1) Specification of both relative and absolute bounding box
    coordinates are worthwhile features to include.

(2) It should be possible to include all data in input files.

(3) The need for a dialog is not clearly established.

Matt