Looking Ahead, Things to do (this could get long)

First off, I am totally excited to see how much has been happening with
Avogadro and LibAvogadro. Really great, ideas are flowing things are
chaining off each other.

Also, I don’t want to preach, but please try to commit code that is
ready for production. We are already seeing commits of “temporary
hack”. This is really bad. People build on previous commits; if
previous commits are bad, then the code committed on top of the bad code
is ALSO bad. Through no fault of the added code’s author. It also
means when that bad code gets fixed, the added code will probably need
to be fixed too. I am not trying to be a dick or anything, but it’s
important to me and I believe it’s really important to the project.
Software Engineering is important as much as it’s a pain in the ass (it
is trust me) but it really pays off. // end lecture

So here is some stuff I’ve been stewing over while I was gone (couldn’t
sleep being excited). I’ll also find a place for this on the WIKI
somewhere (probably in TODO).

== Selection ==
The biggest issue we must resolved immediately, and before we start
implementing new features/changes is the selection issue; Is selection
part of the model (molecule) or part of the view (glwidget). I don’t
think there are objective benefits which make one better over another,
it’s more about what’s more intuitive to the user. Does a user look at
a molecule and expect that no matter how they view the molecule and
select parts of it, that selection stays the same? Does a user look at
a molecule in one view with one selection and expect that to be
different in a different view? I think in general most of us talking on
IRC believe that it’s more a property of the view than of the model.
This also makes it a bit more flexible since maybe in one view i select
a certain thing to modify it, or in another view i select a different
thing to modify without having to go through and reselect everything.
It is not going to effect features, but whichever way we choose, they
will both have different architectures / functions etc. The underlying
code will be different for sure. Both is easy and doable, we just need
to decide.

== Engines ==
In moving forward with engines in Avogadro and LibAvogadro I am
proposing a few updated to the UI. The main idea would be to have a
list of engines, as you select one in the list, below it you are given
two tabs. The first is the settings for the given engine and the second
is a list of all the objects that are rendered for that engine. By
default, any addition of new atoms / bonds are added to all engines.

From the engine list you should be able to duplicate or add new any
engine based on the EngineFactory’s which are loaded from the plugins.

As for saving settings, we should be able to say “hey, here is the
default list of engines that i would like when i startup Avogadro”. We
also need to consider that at some point we will need to save engine
settings WITH the avogadro file. I’m going to go ahead and assume that
most of this will be taken care of by OpenBabel for which we’ll
eventually have to create our own format (CML derivative) and use
OBGenericData to store the extra information from Avogadro. As for
settings etc, those can be stored by the program using the library. We
will need to add ::saveSettings(QSettings settings) function to the
Engine template at some point.

== Colors, Color Schemes and Materials ==
So here is how i would suggest implementing Colors, Color Schemes and
Materials from a code point of view. You pick a material (instance of
the Material class explained below) and apply the material for a given
color (rgba). ColorSchemes are designed to give you a Color (instance
of the Color class containing rgba) based on a primitive / selection /
text. This way an engine will have the option to select the material
and a color scheme. The engine would then take the following steps; get
a pointer to the instance of Material it should use, then for the
current primitive get an instance of Color from the ColorScheme
instance, draw the primitive.

I believe this benefits for a few different reasons. First, if you want
to have certain atoms in one material and certain atoms in another, you
simply duplicate the engine and have each engine only render a subset of
the atoms. The other ideas that I have though about is making
ColorScheme include the material and/or have material also be based off
the primitive, but from a user standpoint, am i going to really want to
go through and setup materials for each element? Probably not. From my
weak chemistry background, it doesn’t seem like you’re ever going to
want a MaterialScheme (material based on primitive). But maybe I am
wrong? This part needs some input from a chemist. I think the idea of
wanting different materials based on primitive is easy enough for the
few users that will want it by simply creating various engines and
setting them to different materials, rather than using a material
scheme. Especially since they can select by smiles.

=== Material ===

The current “”“Color”"" class is actually a “”“Material”"" class.
Material should be a dynamic class which can setup the various OpenGL
properties for rendering. It’s members would represent the various
parameters which you can set for an OpenGL material. Although, we
should provide some set of “preset” materials somehow, simply a static
function which returns lists of Materials would be sufficient, then
allow duplication (copy operator) of materials already instantiated.
Then, we add a class MaterialGroup which an application shares and
gives plugins and applications using libavogadro a common source of
possible materials which they can use when drawing. We could allow
these materials to be copied and modified by the user (through the GUI)
or by the application working with libavogadro and this way we have a
common way for the engines to paint. The Material class should have a
function(s):

  • void ::apply(Color &color,
    Material::Lighting lighting = Material::LightingEnabled);
  • Material ::operator=(Material &other);

Note: I do not believe it’s needed to do subclassing here, most
Materials will have to perform the same procedures, ie. they share the
same code but just different properties. If this is not the case
someone correct me. Also, i don’t think it’s necessary to have
materials changed based off primitives as stated above.

=== Color ===
The “”“Color”"" class should actually be almost a struct which allows
you to set the rgba of a color. It should be simple.

=== ColorScheme ===
The ColorScheme class should be a template class whose subclasses return
instances of Color. We would have a ColorSchemeGroup which you can
add instances of ColorScheme to and manage them (and be shared between
engines). Each color scheme would have a
::settingsWidget just like the engines and tools do. Thus,
we would have function(s):

  • Color ::primitiveColor(Primitive *p) = 0;
  • Color ::selectionColor() = 0;
  • Color ::textColor() = 0;
  • QWidget * ::settingsWidget() = 0;

There are considerations to be made with this class; most notably
depending on the type of color scheme, we benefit from using subclasses
and making ColorScheme a template class. As example is for
ElementColorScheme where the function to do primitiveColor() is based
off OpenBabel::etab and different code from say a class like
UserColorScheme which has a lookup table for each element (this same
functionality could also be built into ElementColorScheme). or even say
UserOddNumberColorScheme which is specialized so that user can say what
colors are odd numbers and what colors are not odd. or say
RadiusColorScheme where colors are determined by the radius of the
atoms. The “internal” functionality between different schemes could and
will be different from scheme to scheme. It is not as simple as
Material where we know exactly what knobs we can turn.

Let me know what you think. Out.


Donald Ephraim Curtis

On Monday 14 May 2007 01:56:09 Donald Ephraim Curtis wrote:

Also, I don’t want to preach, but please try to commit code that is
ready for production. We are already seeing commits of “temporary
hack”. This is really bad.

OK, since I don’t see any other temporary hack recently committed by anyone, I
guess you’re referring to my commits 385-386: “Make a ugly hack so that the
labelengine works with Sphereengine and Sticksengine correctly.”

Should I really have abstained from making those? They fix a rather major
visual bug since the labelengine was only working with the bsdyengine and not
with the other engines. To fix that, I had to tell the GLWidget put the
text-painting engines (such as labelengine) at the end of the list of
engines. That’s not the right way to fix that problem, but we know the right
way, it’s to split Engine::render() into renderOpaque() and
renderTransparent(). It’ll be done soon, in the meanwhile I just wanted to
eliminate a big visual bug from the beta.

But yeah, I understand your concerns, and it’s good that you’re so careful
about that. No problem, you’re not being a “lecturer” :slight_smile:

== Engines ==

Here’s another thing I had in mind about Engines; I already told you about it
on IRC, but I think it’s good to record it on the list:

There should be two categories of Engines:

  • the rendering engines (bdsy, sphere, stick, wire), which paint the molecule
  • the decorating engines (label, debug), which paint some extra information

The rendering engines should be mutually exclusive, i.e. if bsdyengine is
currently active and I enable sphereengine, then bsdyengine gets
automatically disabled. Thus the rendering engines should be exposed with
radio-buttons instead of checkboxes. But the decorating engines are of course
not mutually exclusive.

In addition to this improvement of the user interface, this change would make
it much faster to compute the actual rendering radius of a given atom. The
GLWidget would have a pointer to the active rendering engine, and would
simply call activeRenderingEngine->radius(atom) instead of having to iterate
over all engines, as it currently does. In the current implementation, the
labelengine wastes time determining the radius of atoms.

== Colors, Color Schemes and Materials ==

Before we engage in such a long discussion, a few questions:

  1. will chemists ever want to use more than one material aspect? I know you
    asked the question already but I think it needs to be placed in front of any
    subsequent discussion!
  2. The OpenGL built-in lighting/material model is very naive and does not
    allow to achieve many realistic types of materials. If chemists were really
    interested in having more than one kind of material, I’m not sure they’d be
    satisfied with whatever we could achieve by passing various parameters to
    glMaterial. Basically, glMaterial only covers well the plastic-looking
    materials. Metal can sort-of be achieved but not very well. To achieve nicely
    a broad class of materials, we’d typically need two-pass or three-pass
    rendering. See here for an example : “how to render glass”:
    http://www.opengl.org/resources/faq/technical/transparency.htm#blen0030
    This is just to say that if we really want to support more than just a basic
    default material as we currently have, we need much more than a Material
    class, we need to rethink our rendering pipeline with multiple passes.

Thus, so far, I was assuming that we’d only ever want one kind of material.
That’s why my class was called Color: the only thing it represents is a
Color, one can’t choose a material, it only has a method sending material
parameters to OpenGL based on that color.

Cheers,
Benoit

On Monday 14 May 2007 08:37:55 Benoît Jacob wrote:

This is just to say that if we really want to support more than just a
basic default material as we currently have, we need much more than a
Material class, we need to rethink our rendering pipeline with multiple
passes.

Another approach that I haven’t mentionned, and that is almost necessary to
render Metal, is per-pixel lighting, which is currently fashionable because
all recent graphics cards have programmable pixel shaders. But that’s of
course very slow on platforms that don’t do this in hardware. For instance,
integrated chipsets (a majority of machines still today) can’t do this in
hardware, except for the newly released intel GMA X3000.

To see why e.g. rendering Metal realistically requires per-pixel lighting,
consider that Metal has very tight specular highlights. So the specular
highlight will ofter fall entirely inside one triangle, between the vertices.
So it’ll be ignored by any per-vertex lighting model, such as OpenGL’s
built-in Gouraud model.

Cheers,
Benoit

On May 14, 2007, at 2:37 AM, Benoît Jacob wrote:

OK, since I don’t see any other temporary hack recently committed
by anyone,

I dunno, I’ve certainly added some code with “FIXME” in the comments
to remind that certain design issues need to be addressed (e.g.,
selection). I think this is inevitable. As you say, sometimes you
have a category of bug which needs a more significant effort to fix.
Particularly in a beta release, I think you need to draw the line and
move on from the release.

We can’t fix every bug for this beta release. That’s why I added a
list of known problems for the release notes:
http://avogadro.sourceforge.net/wiki/Avogadro_0.1.0

There should be two categories of Engines:

  • the rendering engines (bdsy, sphere, stick, wire), which paint
    the molecule
  • the decorating engines (label, debug), which paint some extra
    information

The rendering engines should be mutually exclusive, i.e. if
bsdyengine is
currently active and I enable sphereengine, then bsdyengine gets
automatically disabled.

Not really. This is an optimization which seems to make sense now,
but hurts us in the future. Maybe others can comment, but I
definitely have cases where I want to emphasize certain atoms. Maybe
I’m showing hemoglobin and I want to make the iron atom really
obvious. So I pick that a few atoms and render them in “sphere” mode.

http://www.eyesopen.com/images/product/vida_docking.jpg
http://bioinformatics.org/molekel/uploads/gallery/
residues_per_pixel1.png

The second link shows a common protein view. There’s a “ribbon” to
show the general shape of the protein backbone, and then all atoms
are rendered as a wireframe or small balls-and-sticks view.

My original “design outline” for Avogadro said that rendering would
push a set of primitives paired with a particular engine. As Donald
mentioned, this means people could select a set of atoms (e.g., by
SMARTS) and change the rendering style on that set.

Before we engage in such a long discussion, a few questions:

  1. will chemists ever want to use more than one material aspect? I
    know you
    asked the question already but I think it needs to be placed in
    front of any
    subsequent discussion!

I dunno, there’s a range of useful plastics. There’s a more metallic-
like plastic, a dull plastic, … there’s even a somewhat translucent
plastic which might be fun. :slight_smile:

I put some interesting examples up last night:
http://avogadro.sourceforge.net/wiki/Developer:Links#Rendering

In particular:
http://www.ks.uiuc.edu/Research/vmd/minitutorials/glsloutline/
http://qutemol.sourceforge.net/fxs/
http://www.pirx.com/bio_gallery/Image42.html

I’ve seen a number of these images recently which either:

  • Show a more “correct” shadowing
  • Attempt to look like a 2D cartoon style

I haven’t investigated enough to figure out if these are simply
possible with glMaterial, but calling it “Materials” sounds general
enough if people ultimately start putting in more complicated texture
mapping, shaders, etc. I do think Benoit’s point is a good one –
color is likely to be the most significant change people will want.
We should definitely remember the 80/20 rule.

Right now I think we’re spending 20% of the time accomplishing the
80% of the features people will use most. This is a great place to be.

Just my $0.02,
-Geoff

On Monday 14 May 2007 15:49:46 Geoffrey Hutchison wrote:

The rendering engines should be mutually exclusive, i.e. if
bsdyengine is
currently active and I enable sphereengine, then bsdyengine gets
automatically disabled.

Not really. This is an optimization which seems to make sense now,
but hurts us in the future.

OK, I didn’t think about it very deeply, so I’m fine with accepting your
approach. I didn’t know we might render part of a molecule with one engine
and part with another engine.

I’ve seen a number of these images recently which either:

  • Show a more “correct” shadowing
  • Attempt to look like a 2D cartoon style

If you could be more specific, I could try to tell if that’s doable with
glMaterial in a single pass.

Anyway, if it’s important that we allow material variation (beyond just color
varation with fixed material properties) in a given view at a given time, and
if it turns out that that variation can be achieved with the builtin opengl
material/lighting system, then yes we can have a Material class. I’m just
warning you that if what you want requires to override the opengl lighting
system (for instance some of the molekel screenshots suggest that they use
per-pixel lighting) then it’ll require changes that are much deeper than just
writing a Material class.

Cheers,
Benoit

On May 14, 2007, at 10:17 AM, Benoît Jacob wrote:

OK, I didn’t think about it very deeply, so I’m fine with accepting
your
approach. I didn’t know we might render part of a molecule with one
engine
and part with another engine.

No problem at all. It’s clearly not exposed in the user interface
yet, and it’s not clear from the code either. I need to spend some
time putting the design outline on the wiki. :slight_smile:

Donald has also expressed some difficult in understanding residues,
partly because we don’t have a residue engine.

It may be a good idea at some point to separate engines based on
mode, but perhaps separate renderPrimitive(), renderTransparent() and
renderText() or renderOverlay() will be enough.

warning you that if what you want requires to override the opengl
lighting
system (for instance some of the molekel screenshots suggest that
they use
per-pixel lighting) then it’ll require changes that are much deeper
than just
writing a Material class.

Yes, this makes sense. I don’t think we know yet, so we’ll have to
wait and see. One problem with a simple design outline is that
"what’s possible" often forces changes to the design.

Cheers,
-Geoff

P.S. I think in terms of Kalzium 4, you may want to have a user
interface with radio buttons (or a popup menu) for the different
engines. This is certainly less confusing.

So, in finding a bug while developing today i realized there is one
major argument for selection being part of the model (molecule) rather
than the view (glwidget). If selection is part of the model we can have
it as part of the undo/redo stack. That is, we can have “undo select
all” or “undo select inverse” or something like that. However, if it’s
part of the view we’re going to run into issues because the views can be
created and/or destroyed.

Regardless, no QUndoCommand subclass should ever be concerned with the
glWidget because they are created as easily as they are destroyed.


Donald

(Mon, May 14, 2007 at 11:08:06AM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:

On May 14, 2007, at 10:17 AM, Benoît Jacob wrote:

OK, I didn’t think about it very deeply, so I’m fine with accepting
your
approach. I didn’t know we might render part of a molecule with one
engine
and part with another engine.

No problem at all. It’s clearly not exposed in the user interface
yet, and it’s not clear from the code either. I need to spend some
time putting the design outline on the wiki. :slight_smile:

Donald has also expressed some difficult in understanding residues,
partly because we don’t have a residue engine.

It may be a good idea at some point to separate engines based on
mode, but perhaps separate renderPrimitive(), renderTransparent() and
renderText() or renderOverlay() will be enough.

warning you that if what you want requires to override the opengl
lighting
system (for instance some of the molekel screenshots suggest that
they use
per-pixel lighting) then it’ll require changes that are much deeper
than just
writing a Material class.

Yes, this makes sense. I don’t think we know yet, so we’ll have to
wait and see. One problem with a simple design outline is that
"what’s possible" often forces changes to the design.

Cheers,
-Geoff

P.S. I think in terms of Kalzium 4, you may want to have a user
interface with radio buttons (or a popup menu) for the different
engines. This is certainly less confusing.

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
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

On Tuesday 15 May 2007 09:06:16 Donald Ephraim Curtis wrote:

So, in finding a bug while developing today i realized there is one
major argument for selection being part of the model (molecule) rather
than the view (glwidget). If selection is part of the model we can have
it as part of the undo/redo stack. That is, we can have “undo select
all” or “undo select inverse” or something like that. However, if it’s
part of the view we’re going to run into issues because the views can be
created and/or destroyed.

Regardless, no QUndoCommand subclass should ever be concerned with the
glWidget because they are created as easily as they are destroyed.

I thought I should post a reply to the list after talking with you about this
earlier. I don’t think that selection undo/redo support is necessarily
needed. The way in which selections are currently made you can’t easily undo
a big selection that has taken some time with a single click.

Selections don’t change anything directly but facilitate changes that are
recorded in the model. So the manipulate tool certainly needs undo/redo
support adding to it. I would be interested to hear what others might think
on this issue too.

Thanks,

Marcus

On Monday 14 May 2007 00:56:09 Donald Ephraim Curtis wrote:

== Selection ==
The biggest issue we must resolved immediately, and before we start
implementing new features/changes is the selection issue; Is selection
part of the model (molecule) or part of the view (glwidget). I don’t
think there are objective benefits which make one better over another,
it’s more about what’s more intuitive to the user. Does a user look at
a molecule and expect that no matter how they view the molecule and
select parts of it, that selection stays the same? Does a user look at
a molecule in one view with one selection and expect that to be
different in a different view? I think in general most of us talking on
IRC believe that it’s more a property of the view than of the model.
This also makes it a bit more flexible since maybe in one view i select
a certain thing to modify it, or in another view i select a different
thing to modify without having to go through and reselect everything.
It is not going to effect features, but whichever way we choose, they
will both have different architectures / functions etc. The underlying
code will be different for sure. Both is easy and doable, we just need
to decide.

You know my views here - I favour it being part of the view and think that
this will lead to increased productivity. I think when working with large
structures being able to work on specific parts in different views would be
the most productive and intuitive way to work.

== Engines ==
In moving forward with engines in Avogadro and LibAvogadro I am
proposing a few updated to the UI. The main idea would be to have a
list of engines, as you select one in the list, below it you are given
two tabs. The first is the settings for the given engine and the second
is a list of all the objects that are rendered for that engine. By
default, any addition of new atoms / bonds are added to all engines.

This sounds like a great way to implement the feature of being able to
visualise different parts of the molecule with different engines.

From the engine list you should be able to duplicate or add new any

engine based on the EngineFactory’s which are loaded from the plugins.

As for saving settings, we should be able to say “hey, here is the
default list of engines that i would like when i startup Avogadro”. We
also need to consider that at some point we will need to save engine
settings WITH the avogadro file. I’m going to go ahead and assume that
most of this will be taken care of by OpenBabel for which we’ll
eventually have to create our own format (CML derivative) and use
OBGenericData to store the extra information from Avogadro. As for
settings etc, those can be stored by the program using the library. We
will need to add ::saveSettings(QSettings settings) function to the
Engine template at some point.

Would we also be able to effectively save a work space? I was thinking if you
were working on a large structure and had multiple views open it would be
useful to be able to save the views and the associated engine
setting/selections. Not sure how easy it would be to serialise all that data
though.

== Colors, Color Schemes and Materials ==
So here is how i would suggest implementing Colors, Color Schemes and
Materials from a code point of view. You pick a material (instance of
the Material class explained below) and apply the material for a given
color (rgba). ColorSchemes are designed to give you a Color (instance
of the Color class containing rgba) based on a primitive / selection /
text. This way an engine will have the option to select the material
and a color scheme. The engine would then take the following steps; get
a pointer to the instance of Material it should use, then for the
current primitive get an instance of Color from the ColorScheme
instance, draw the primitive.

I believe this benefits for a few different reasons. First, if you want
to have certain atoms in one material and certain atoms in another, you
simply duplicate the engine and have each engine only render a subset of
the atoms. The other ideas that I have though about is making
ColorScheme include the material and/or have material also be based off
the primitive, but from a user standpoint, am i going to really want to
go through and setup materials for each element? Probably not. From my
weak chemistry background, it doesn’t seem like you’re ever going to
want a MaterialScheme (material based on primitive). But maybe I am
wrong? This part needs some input from a chemist. I think the idea of
wanting different materials based on primitive is easy enough for the
few users that will want it by simply creating various engines and
setting them to different materials, rather than using a material
scheme. Especially since they can select by smiles.

I am not quite sure what the interface would look like but it sounds like a
flexible solution to me. Do you have an idea of what you see the interface
looking like and how many options you would like to expose? I have seen some
packages allowing you to change colour, material, lighting, angle light comes
from and lots of bits like that. Then you can add a rainbow background :slight_smile:

I am sure the beta will spark more feedback and I have already had some
feedback from people I have showed Avogadro too. There are other things we
have come up with too as we have discussed it and added them to the todo
page.

There is also the kalzium port to libavogadro. Lots to figure out but we
should be able to work it all out. I am going to delve into CMake tommorrow
to see what I can accomplish there.

Thanks,

Marcus

On May 15, 2007, at 6:32 PM, Marcus D. Hanwell wrote:

two tabs. The first is the settings for the given engine and the
second
is a list of all the objects that are rendered for that engine. By
default, any addition of new atoms / bonds are added to all engines.
This sounds like a great way to implement the feature of being able to
visualise different parts of the molecule with different engines.

Oh, that reminds me. We should add a “hide” engine. Something which
actively hides atoms. Some people like to hide hydrogen atoms, for
example. Should be an easy engine to code. Although this brings up
the question of whether an extension can affect engines and tools.

You know my views here - I favour it being part of the view and
think that
this will lead to increased productivity.

I think we’re all agreed, so when I get a chance, I’ll just
obliterate any code which does it the other way. Donald, I think you
said there would be a PrimitiveList class which had separate QList
for all primitives?

Would we also be able to effectively save a work space? I was
thinking if you
were working on a large structure and had multiple views open it
would be
useful to be able to save the views and the associated engine
setting/selections.

To me, that sounds like something you want to save in the molecule
file. That will take some time to build up the appropriate
infrastructure. I think it’s a good idea and certainly doable.

The tricky part I see with open/save is dealing with multiple-record
files. I can imagine good ways to deal with reading them, but writing
gets tricky. You basically have to take apart the file.

Anyway, there’s clearly plenty of interesting things to do going
forward.

Cheers,
-Geoff

So, i’m kinda going to list some things i see that need to be done.
Just real quick and easy things but a little more specific than the
ToDo.

  • Rename PrimitiveQueue -> PrimitiveList . This is already created it
    just needs proper naming (Maybe “List” isn’t the proper name either,
    it’s a set of lists basically, Maybe a PrimitiveListSet) and i think we
    should remove it from the primitive.h header and make it it’s own
    primitivelist.h (primitivelistset.h). It’s not a HUGE deal just
    something i’m mentioning and i’ll get around to it sooner or later.

  • Move all selection code to the “View”. IMO the fact that something
    is selected should be equivalent if it’s in the GLWidget::selectionList.
    Really easy. If it’s not in the list, it’s not selected.

  • You can see i have added another dock that has “Engine Configuration”.
    There is only one tab currently, but there will be another soon enough
    "Primitives" which will be a list of the Primitives associated with an
    Engine. Then there should be buttons in this tab; add selection, remove
    selection, add all, clear etc etc. This would address the “hide” engine
    thing.

Just some things.


Donald

(Tue, May 15, 2007 at 09:41:14PM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:

On May 15, 2007, at 6:32 PM, Marcus D. Hanwell wrote:

two tabs. The first is the settings for the given engine and the
second
is a list of all the objects that are rendered for that engine. By
default, any addition of new atoms / bonds are added to all engines.
This sounds like a great way to implement the feature of being able to
visualise different parts of the molecule with different engines.

Oh, that reminds me. We should add a “hide” engine. Something which
actively hides atoms. Some people like to hide hydrogen atoms, for
example. Should be an easy engine to code. Although this brings up
the question of whether an extension can affect engines and tools.

You know my views here - I favour it being part of the view and
think that
this will lead to increased productivity.

I think we’re all agreed, so when I get a chance, I’ll just
obliterate any code which does it the other way. Donald, I think you
said there would be a PrimitiveList class which had separate QList
for all primitives?

Would we also be able to effectively save a work space? I was
thinking if you
were working on a large structure and had multiple views open it
would be
useful to be able to save the views and the associated engine
setting/selections.

To me, that sounds like something you want to save in the molecule
file. That will take some time to build up the appropriate
infrastructure. I think it’s a good idea and certainly doable.

The tricky part I see with open/save is dealing with multiple-record
files. I can imagine good ways to deal with reading them, but writing
gets tricky. You basically have to take apart the file.

Anyway, there’s clearly plenty of interesting things to do going
forward.

Cheers,
-Geoff


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
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

On May 21, 2007, at 10:39 AM, Donald Ephraim Curtis wrote:

So, i’m kinda going to list some things i see that need to be done.
Just real quick and easy things but a little more specific than the
ToDo.

I’m in the middle of a few things, but wanted to ask about Qt-4.3.
IIRC, we can use the new dock widgets?
http://doc.trolltech.com/4.3/qt4-3-intro.html

Cheers,
-Geoff

Yes, we need to bump our requirement for Avogadro / LibAvogadro to 4.3
sometime. Gentoo just pushed the new version to portage, not sure
Ubuntu’s status but it’s going to be out soon enough i’m guessing.

(Mon, May 21, 2007 at 11:58:39AM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:

On May 21, 2007, at 10:39 AM, Donald Ephraim Curtis wrote:

So, i’m kinda going to list some things i see that need to be done.
Just real quick and easy things but a little more specific than the
ToDo.

I’m in the middle of a few things, but wanted to ask about Qt-4.3. IIRC, we
can use the new dock widgets?
http://doc.trolltech.com/4.3/qt4-3-intro.html

Cheers,
-Geoff

On Monday 14 May 2007 15:49:46 Geoffrey Hutchison wrote:

I’ve seen a number of these images recently which either:

  • Show a more “correct” shadowing

I have tweaked the light and material parameters. Hope it looks more "correct"
now :slight_smile:

-Benoit

On May 23, 2007, at 3:00 AM, Benoît Jacob wrote:

I have tweaked the light and material parameters. Hope it looks
more "correct"
now :slight_smile:

I was referring more to the ambient occlusion modeling:
http://qutemol.sourceforge.net/

But of course the new tweaks are definitely nice. Ignoring the
ambient occlusion shadowing (which I think requires some OpenGL
extensions), I think we have the best rendering quality that I’ve
seen. :slight_smile:

Cheers,
-Geoff

On Wednesday 23 May 2007 14:57:57 Geoffrey Hutchison wrote:

On May 23, 2007, at 3:00 AM, Benoît Jacob wrote:

I have tweaked the light and material parameters. Hope it looks
more "correct"
now :slight_smile:

I was referring more to the ambient occlusion modeling:
http://qutemol.sourceforge.net/

Wow, very impressive. They say they use OpenGL shaders. Indeed, this can’t be
done with the builtin lighting/shading system of OpenGL.

I’ve just realized that even my basic intel chipset has programmable shaders.
So using shaders perhaps isn’t as optimistic as I had thought. Anyway, I
don’t have any experience with programmable shaders so I won’t be able to do
that kind of stuff anytime soon. Maybe we can simply reuse QuteMol’s
rendering code as an alternative option (alongside with the current rendering
code we have) for those users who have appropriate hardware. QuteMol says
it’s GPL’d, so copy-and-pasting code is allowed. However, looking at source
files, it seems that GPL headers are missing.

On another note, as a special treat for those who have powerful hardware, we
could provide an option to turn on full-scene anti-aliasing. (I even seem to
remember you proposed that a long time ago). The only problem is that this
requires the GLWidget to be reinitialized, but it is certainly easy to add at
least as a command-line option. Would be nice for screenshots. I’m afraid my
hardware doesn’t support FSAA, so I couldn’t test that feature.

Another thing is fog. A black fog can make the relative distances of atoms
more obvious to the eye. There was fog in Kalzium3D, it’s trivial to turn on
(should be handled by Camera::applyPerspective), tell me if you’d like it.

Cheers,
Benoit

On May 23, 2007, at 9:28 AM, Benoît Jacob wrote:

On another note, as a special treat for those who have powerful
hardware, we
could provide an option to turn on full-scene anti-aliasing. (I
even seem to
remember you proposed that a long time ago).

It already does. From main.cpp:
// use multi-sample (anti-aliased) OpenGL if available
QGLFormat defFormat = QGLFormat::defaultFormat();
defFormat.setSampleBuffers(true);
QGLFormat::setDefaultFormat(defFormat);

My understanding is that QGLFormat will automatically back off if
anti-aliasing is not available. Check the edges of the spheres
against a white background color. Mine are definitely multi-sampled.

There was fog in Kalzium3D, it’s trivial to turn on (should be
handled by Camera::applyPerspective), tell me if you’d like it.

I think these should be global rendering options. Some people don’t
like the fog effect. But it’s good to offer that, and maybe being
able to switch perspective options.

Cheers,
-Geoff

On Wednesday 23 May 2007 15:39:46 Geoffrey Hutchison wrote:

On May 23, 2007, at 9:28 AM, Benoît Jacob wrote:

On another note, as a special treat for those who have powerful
hardware, we
could provide an option to turn on full-scene anti-aliasing. (I
even seem to
remember you proposed that a long time ago).

It already does. From main.cpp:
// use multi-sample (anti-aliased) OpenGL if available
QGLFormat defFormat = QGLFormat::defaultFormat();
defFormat.setSampleBuffers(true);
QGLFormat::setDefaultFormat(defFormat);

My understanding is that QGLFormat will automatically back off if
anti-aliasing is not available. Check the edges of the spheres
against a white background color. Mine are definitely multi-sampled.

Wow!! I didn’t know that. I never saw the multisampling because my system
doesn’t do it.

There was fog in Kalzium3D, it’s trivial to turn on (should be
handled by Camera::applyPerspective), tell me if you’d like it.

I think these should be global rendering options. Some people don’t
like the fog effect. But it’s good to offer that, and maybe being
able to switch perspective options.

Yes, I was also thinking about that as a global rendering option.

I’m adding a TODO item about reusing QuteMol’s rendering code.

Benoit