Hi,
I just wanted to provide a brief update on my progress. I got back into some
coding this week and have added what you guys hopefully see as some useful
new features.
I have added an axes engine that draws the x, y and z axes in a fixed position
at the bottom left of the screen in the three primary colours - it seemed
appropriate. Thanks to Benoit for lots of pointers to figure out how to do
this and keep it at a fixed size at all times.
I wanted to label the axes x, y and z but the drawText function does not draw
to the coordinates in my projection matrix. Right now I am not sure what the
best way to add labels to this engine might be - suggestions would be
appreciated. I think it is a nice visual cue as to how the view is being
rotated even in its current unlabelled form.
I have also added an autorotation tool. You can set the x, y and z rotations
using sliders and it is working quite well here. I was thinking of extending
it so that it kills the timer if all rotation values are zero and then starts
a timer if not. It doesn’t seem to have any performance impact in its current
state where there is always a timer on my system.
I was also considering adding a mouse gestures style setting of rotation
speeds too. It would complicate the engine a little. Would it be more
intuitive to kill the timer if the tool is not selected?
I have also made some additions to the VdW engine. I am particularly proud of
this but I didn’t know if it should be a separate engine or part of the VdW
engine. The transparency does really kill performance on my unaccelerated
laptop - typically goes from 20 - 10 fps here.
I have added bond labels to the label engine. I don’t know if it makes more
sense to have bond indexes start at 1 as the atom indexes do. Right now the
engines take care of incrementing the index by 1 as a 0 index was invalid and
led to one unselectable bond.
I have spotted a bug in selection box picking too but I can’t figure out where
it is coming from. When an atom is bonded and you select the atom using a box
the hits function also returns the bond with the same index (-1 due to the
increment/decrement). I have done some initial debugging using qDebug() calls
but can’t spot why this is happening and I am sure it wasn’t happening when I
first implemented this feature as I remember testing it all out.
Not as brief as I intended but I thought it would be good to update you on
what I have been up to so far this week.
Thanks,
Marcus
Moin
I have added an axes engine that draws the x, y and z axes in a fixed position
at the bottom left of the screen in the three primary colours - it seemed
appropriate.
Is it me or are the axis not 90°?
I find the blue a bit dark.
I have also added an autorotation tool. You can set the x, y and z rotations
using sliders and it is working quite well here. I was thinking of extending
it so that it kills the timer if all rotation values are zero and then starts
a timer if not. It doesn’t seem to have any performance impact in its current
state where there is always a timer on my system.
Nice 
But I am missing an easy way to set the rotation to 0.
Currently 0 is in the middle of the slider. Perhaps a slider with left
== 0 and right == maximum would be better and the a combox for
positive/negative rotation?
Very nice changes!!
Carsten
On Wednesday 13 June 2007 12:09:01 you wrote:
Moin
I have added an axes engine that draws the x, y and z axes in a fixed
position at the bottom left of the screen in the three primary colours -
it seemed appropriate.
Is it me or are the axis not 90°?
They may have some perspective effects - they get their directions from the
views space projection matrix. They do look like they are at 90 on my TFT
screen though when the view is first initialised.
I find the blue a bit dark.
Looks great here - I guess it is dependent upon your display. Their colour
could probably be made a configuration option. They are all set to have 0, 0
and then 1 of whichever colour they are.
I have also added an autorotation tool. You can set the x, y and z
rotations using sliders and it is working quite well here. I was thinking
of extending it so that it kills the timer if all rotation values are
zero and then starts a timer if not. It doesn’t seem to have any
performance impact in its current state where there is always a timer on
my system.
Nice But I am missing an easy way to set the rotation to 0.
Currently 0 is in the middle of the slider. Perhaps a slider with left
== 0 and right == maximum would be better and the a combox for
positive/negative rotation?
Yeah I started off with just positive rotation. I think an extra combobox for
each axis would make the configuration unnecessarily crowded. How about a
button - reset all axes or something like that? You press it and all sliders
are reset to 0. May be adding some number markers would help visually too.
I was considering a start/stop button and may be a reset button at the bottom
of the configuration dialog.
I know there is some known issues with the selection tool and using the box.
Most notably, if there are two different engines rendering the same thing,
you get multiple hits. That’s actually ok, it’s just that the selection tool
needs to make a “preliminary” list of all the atoms to toggle selection and
make sure there are no duplicates.
I’m not sure if this is related. I’ve gotta take care of a few things but
please file a bug and we’ll definatly get to this and maybe it’s something i
can help you with soon.
–
Donald
On Wednesday 13 June 2007 05:26:59 am Marcus D. Hanwell wrote:
Hi,
I just wanted to provide a brief update on my progress. I got back into
some coding this week and have added what you guys hopefully see as some
useful new features.
I have added an axes engine that draws the x, y and z axes in a fixed
position at the bottom left of the screen in the three primary colours - it
seemed appropriate. Thanks to Benoit for lots of pointers to figure out how
to do this and keep it at a fixed size at all times.
I wanted to label the axes x, y and z but the drawText function does not
draw to the coordinates in my projection matrix. Right now I am not sure
what the best way to add labels to this engine might be - suggestions would
be appreciated. I think it is a nice visual cue as to how the view is being
rotated even in its current unlabelled form.
I have also added an autorotation tool. You can set the x, y and z
rotations using sliders and it is working quite well here. I was thinking
of extending it so that it kills the timer if all rotation values are zero
and then starts a timer if not. It doesn’t seem to have any performance
impact in its current state where there is always a timer on my system.
I was also considering adding a mouse gestures style setting of rotation
speeds too. It would complicate the engine a little. Would it be more
intuitive to kill the timer if the tool is not selected?
I have also made some additions to the VdW engine. I am particularly proud
of this but I didn’t know if it should be a separate engine or part of the
VdW engine. The transparency does really kill performance on my
unaccelerated laptop - typically goes from 20 - 10 fps here.
I have added bond labels to the label engine. I don’t know if it makes more
sense to have bond indexes start at 1 as the atom indexes do. Right now the
engines take care of incrementing the index by 1 as a 0 index was invalid
and led to one unselectable bond.
I have spotted a bug in selection box picking too but I can’t figure out
where it is coming from. When an atom is bonded and you select the atom
using a box the hits function also returns the bond with the same index (-1
due to the increment/decrement). I have done some initial debugging using
qDebug() calls but can’t spot why this is happening and I am sure it wasn’t
happening when I first implemented this feature as I remember testing it
all out.
Not as brief as I intended but I thought it would be good to update you on
what I have been up to so far this week.
Thanks,
Marcus
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
On Wednesday 13 June 2007 17:22:41 Donald Ephraim Curtis wrote:
I know there is some known issues with the selection tool and using the
box. Most notably, if there are two different engines rendering the same
thing, you get multiple hits. That’s actually ok, it’s just that the
selection tool needs to make a “preliminary” list of all the atoms to
toggle selection and make sure there are no duplicates.
I’m not sure if this is related. I’ve gotta take care of a few things but
please file a bug and we’ll definatly get to this and maybe it’s something
i can help you with soon.
I managed to spot the mistake and it was mine 
I must have forgotten to
decrement the hit.name() call in the case of selection boxes - after quite a
few qDebug() lines and selection testing I spotted it.
I have hit another weird problem now but it is probably something I am doing
wrong again… With the autorotatetool I had the idea of subclassing QWidget
and making a configuration widget that could reset the sliders and
everything. Whenever I add the new class to the autorotatetool.* files, or
even in separate source files that I link to the tool it prevents the tool
from beng loaded.
More qDebug() statements confirm that the QObject *instance =
loader.instance(); call fails and it gives a null reference. I stripped
everything out of my widget class and it still prevents loading. If anyone
can spot what I am missing I would love to know - it has been driving me
crazy. I do know lots more about how we load plugins, the Qt interfaces and
have read much more of the Avogadro codebase
Thanks,
Marcus
On Jun 13, 2007, at 6:26 AM, Marcus D. Hanwell wrote:
I have added an axes engine that draws the x, y and z axes in a
fixed position
at the bottom left of the screen in the three primary colours - it
seemed
appropriate.
This is definitely a common way to do it. Personally, I’d also love
to have an option to draw the axes as 1.0A lines through the origin.
Sometimes it helps to have these as a reference in the molecule.
I have also made some additions to the VdW engine. I am
particularly proud of
this but I didn’t know if it should be a separate engine or part of
the VdW
engine. The transparency does really kill performance on my
unaccelerated
laptop - typically goes from 20 - 10 fps here.
This is cool, but would it work better to just draw the spheres and
let another engine draw in the middle? This way someone could use the
sticks or wireframe view if they wanted – and not just the balls-and-
sticks option. (Or maybe they want nothing in the middle, just semi-
transparent spheres.)
I think this really highlights the fun of multiple overlaying engines!
Cheers,
-Geoff
On Sunday 17 June 2007 15:01:31 Geoffrey Hutchison wrote:
On Jun 13, 2007, at 6:26 AM, Marcus D. Hanwell wrote:
I have added an axes engine that draws the x, y and z axes in a
fixed position
at the bottom left of the screen in the three primary colours - it
seemed
appropriate.
This is definitely a common way to do it. Personally, I’d also love
to have an option to draw the axes as 1.0A lines through the origin.
Sometimes it helps to have these as a reference in the molecule.
I had considered doing this - I don’t think it would be hard and could
certainly be added as an option to the engine.
I have also made some additions to the VdW engine. I am
particularly proud of
this but I didn’t know if it should be a separate engine or part of
the VdW
engine. The transparency does really kill performance on my
unaccelerated
laptop - typically goes from 20 - 10 fps here.
This is cool, but would it work better to just draw the spheres and
let another engine draw in the middle? This way someone could use the
sticks or wireframe view if they wanted – and not just the balls-and-
sticks option. (Or maybe they want nothing in the middle, just semi-
transparent spheres.)
I think this really highlights the fun of multiple overlaying engines!
This was what I originally tried to do. Rendering order is very important
though - this engine would need to go after the other rendering engines. I
had thought about proposing some changes to the engines API so that a
rendering order could be imposed somehow.
Possibly engine types or something. So atom drawing, transparent atom drawing,
labelling or an equivalent to usefulness such as render priority? I thought
classification could be useful so that the engines could possibly be grouped
in future.
It would need some way of ensuring the transparent engine was rendered after
the engine that draws the backbone. You might also want the labels on the
backbone rather than the transparent engine and so the label engine should be
called before the transparent engine in that case.
I wasn’t sure if Donald might have some ideas on the best way of abstracting
this. Glad you like it although I totally agree it would be way cooler if it
could use any other engine or none at all to draw the backbone.
Thanks,
Marcus