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

[Wolfram Quester]

Hi Matt,

thanks for your work and the detailed answer!

On Wed, Mar 31, 2004 at 11:58:45AM +0100, Matt Hodges wrote:
> >>>>> Wolfram Quester writes:
> 
[...snip...]
> 
>  > But this is the only warning that remains. Then I fixed a typo in
>  > the man-page stating -G switches GL rendering on. I also replaced -
>  > with \- to get a proper representation in UTF-8 terminals.
> 
> 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.

[...snip...]
> 
>  > It has one big bug, which makes it rather unusable and I'm not sure
>  > how to handle it: You can't do anything with it when "Rotate about
>  > local COM" is on. Everything works well if one uses "Rotate about
>  > origin".
> 
> 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 tried to be as little invasive as poosible, but every solution I
>  > can think of for this problem is quite big. One would be to treat
>  > every corner of the bbox like an atom. But I guess I've just missed
>  > something obvious. Perhaps you have a hint which line I have to
>  > change to resolve this issue.
> 
> 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.

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.
> 
>  > To summarize:
>  > - The patch adds a menu entry "Edit -> Bounding Box" which allows to
>  >   choose if the bounding box is calculated automatically or by hand. You
>  >   can enter the box coordinates here. The manual bbox can be initialized
>  >   from the automatical calculation.
> 
> This is fine.
But it is no more necessary with your patch, because it is done
automatically.
> 
>  > - The thing is only functional when we rotate about the origin. Then it
>  >   is also possible to use center/original orientation/original position
>  >   from the track menu.
>  > - It does not play together with the new scaling and the reflect and
>  >   invert items in the track menu because this is fast done after the
>  >   other big problem is solved.
> 
> 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.
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.
> 
>  > - It would be nice if the coordinates of the bounding box could be read
>  >   from the .xyz file.
> 
> 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.
> 
>  > - I'll take care about these two if the rotation about local COM is
>  >   fixed.
> 
> I think it is fixed.
Yes, but let me await your response to the above mentioned things ;-)

Thanks,

Wolfi
> 
> Matt
>

signature.asc
Description: Digital signature