Fwd: Avogadro inside of a python GUI

Hi Tim – Do you still have this script around?

---------- Forwarded message ----------
From: Cecil O’Dell noxstant@gmail.com
Date: Mon, Jul 11, 2011 at 8:51 AM
Subject: Re: [Avogadro-devel] Avogadro inside of a python GUI
To: David Lonie loniedavid@gmail.com

On Mon, Jul 11, 2011 at 8:48 AM, David Lonie loniedavid@gmail.com wrote:

On Sat, Jul 9, 2011 at 12:31 PM, Cecil O’Dell noxstant@gmail.com wrote:

Dear Avogadro developers,

I came across one man’s blog that claimed to have loaded Avogadro’s C++
libraries into 65 lines of python script and had a picture of it slowing
various molecular displays. Yet the code is nowhere to be found. Does anyone
know where I can access this code? It would be very beneficial to the
project I am currently working on.

Can you provide a link to the blog?

Thanks,

Cecil


All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

A while ago I asked about the prospect for volume rendering (and better-scalable rendering in Avogadro in general). I was told there was a VTK integration in the works, but I haven’t heard about it since then.

Also, VTK has pretty awful support for volume rendering – it really wasn’t designed for that.

So far I’ve been using my own custom tool, an interactive direct volume renderer that supports large-scale ball and stick vis. Some examples are here:
http://www.mcs.anl.gov/~knoll/supersoot/supersoot_bas9.png
http://www.mcs.anl.gov/~knoll/supersoot/supersoot_bas7.png

My motivation: my users (and myself) love the Avogadro interface and would like to use it if possible.

What would be involved in modifying Avogadro to support an interactive GPU raycasting rendering backend? I understand this may not replace rasterization outright (for backwards compatibility and speed reasons), but for a lot of visualization this would be a huge improvement.

-Aaron


Aaron Knoll
Computational Postdoc Fellow
FuturesLab Vis Group
Mathematics and Computer Science
http://www.mcs.anl.gov/~knoll
knoll@mcs.anl.gov

On Jul 11, 2011, at 6:56 AM, David Lonie wrote:

Hi Tim – Do you still have this script around?

---------- Forwarded message ----------
From: Cecil O’Dell noxstant@gmail.com
Date: Mon, Jul 11, 2011 at 8:51 AM
Subject: Re: [Avogadro-devel] Avogadro inside of a python GUI
To: David Lonie loniedavid@gmail.com

http://timvdm.blogspot.com/2009/05/using-avogadro-library-from-python.html

On Mon, Jul 11, 2011 at 8:48 AM, David Lonie loniedavid@gmail.com wrote:

On Sat, Jul 9, 2011 at 12:31 PM, Cecil O’Dell noxstant@gmail.com wrote:

Dear Avogadro developers,

I came across one man’s blog that claimed to have loaded Avogadro’s C++
libraries into 65 lines of python script and had a picture of it slowing
various molecular displays. Yet the code is nowhere to be found. Does anyone
know where I can access this code? It would be very beneficial to the
project I am currently working on.

Can you provide a link to the blog?

Thanks,

Cecil


All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel


All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel


Aaron Knoll
Computational Postdoc Fellow
FuturesLab Vis Group
Mathematics and Computer Science
http://www.mcs.anl.gov/~knoll
knoll@mcs.anl.gov

A while ago I asked about the prospect for volume rendering (and better-scalable rendering in Avogadro in general). I was told there was a VTK integration in the works, but I haven’t heard about it since then.
Also, VTK has pretty awful support for volume rendering – it really wasn’t designed for that.

Well, I think Marcus will have some thoughts on that. VTK now has GPU-rendered volume rendering. He’s also been thinking for a while about better scaling rendering, which I think would be delivered in an Avogadro 2.0 effort once we get 1.1/1.2 out the door this summer and fall.

So far I’ve been using my own custom tool, an interactive direct volume renderer that supports large-scale ball and stick vis. Some examples are here:
http://www.mcs.anl.gov/~knoll/supersoot/supersoot_bas9.png
http://www.mcs.anl.gov/~knoll/supersoot/supersoot_bas7.png

Well, I’d personally love to have non-VTK volumetric rendering.

My motivation: my users (and myself) love the Avogadro interface and would like to use it if possible.

Great to hear!

What would be involved in modifying Avogadro to support an interactive GPU raycasting rendering backend? I understand this may not replace rasterization outright (for backwards compatibility and speed reasons), but for a lot of visualization this would be a huge improvement.

Well, there is already a GLSL extension when available, and much can be done with this – personally, I’ve been concentrating on building/editing tools so a

Beyond that, you’d probably need to start on a new Painter class. We’ve tried to isolate real rendering calls into this class, so the Pov-Ray or other export methods use custom Painters.

-Geoff

On Thu, Jul 14, 2011 at 1:24 PM, Geoffrey Hutchison <
geoff.hutchison@gmail.com> wrote:

A while ago I asked about the prospect for volume rendering (and
better-scalable rendering in Avogadro in general). I was told there was a
VTK integration in the works, but I haven’t heard about it since then.
Also, VTK has pretty awful support for volume rendering – it really
wasn’t designed for that.

Well, I think Marcus will have some thoughts on that. VTK now has
GPU-rendered volume rendering. He’s also been thinking for a while about
better scaling rendering, which I think would be delivered in an Avogadro
2.0 effort once we get 1.1/1.2 out the door this summer and fall.

Do you mean the old CPU based volume rendering code? Since VTK 5.6 (with
improvements in the upcoming 5.8) there is a fast volume rendering component
(originally developed for VTKEdge). I have a VTK plugin that uses the volume
rendering in VTK (up on Github), but it is fairly experimental proof of
concept stuff at this stage. We also have a Google Summer of Code student
(David Lonie) working on adding support for rendering chemical structure in
VTK.

I think there is some very interesting new work going into VTK, and I have
put quite a bit of work into that myself. I am also interested in the Manta
work for real-time raytracing. That said, I would be open to looking at
other approaches. I am hoping that I will be able to devote significant time
to Avogadro 2.0 development in the near future, and many aspects would
address scaling (there are issues in both our data model and our rendering
there).

So far I’ve been using my own custom tool, an interactive direct volume
renderer that supports large-scale ball and stick vis. Some examples are
here:
http://www.mcs.anl.gov/~knoll/supersoot/supersoot_bas9.png
http://www.mcs.anl.gov/~knoll/supersoot/supersoot_bas7.png

Well, I’d personally love to have non-VTK volumetric rendering.

Why specifically non-VTK volume rendering Geoff? If it is the Mac issue I
believe that is close to being resolved. Is this rendering code available? I
had a look on your site and couldn’t find anything. I am certainly
interested in what you have.

My motivation: my users (and myself) love the Avogadro interface and
would like to use it if possible.

Great to hear!

Seconded - I would like to ensure it remains useful and having input from
you and others helps a lot there.

What would be involved in modifying Avogadro to support an interactive
GPU raycasting rendering backend? I understand this may not replace
rasterization outright (for backwards compatibility and speed reasons), but
for a lot of visualization this would be a huge improvement.

Well, there is already a GLSL extension when available, and much can be
done with this – personally, I’ve been concentrating on building/editing
tools so a

Beyond that, you’d probably need to start on a new Painter class. We’ve
tried to isolate real rendering calls into this class, so the Pov-Ray or
other export methods use custom Painters.

That would be a logical way to go - add a new Painter class. I would love to
discuss this further, and am interested in what you have available.

Thanks,

Marcus

On Jul 18, 2011, at 6:57 PM, Marcus D. Hanwell wrote:

Why specifically non-VTK volume rendering Geoff? If it is the Mac issue I believe that is close to being resolved. Is this rendering code available? I had a look on your site and couldn’t find anything. I am certainly interested in what you have.

I’m just interested in a default dependency-free version. IMHO, it’s a good thing that Avo has very few dependencies and is easy to compile. I know VTK is becoming more modular and easier to compile, but it’s still a pretty big addition. (Consider that I develop on Mac, and while there are Qt binaries, there are no VTK binaries.)

So yes, if someone has a non-VTK volume rendering code they’d like to contribute, I’ll gladly work with them to help get it going.

-Geoff

P.S. Aaron – you don’t happen to also have ambient occlusion, do you? I’ve always liked the effects in QuteMol and VMD. :slight_smile:

On Mon, Jul 18, 2011 at 9:50 PM, Geoffrey Hutchison <
geoff.hutchison@gmail.com> wrote:

On Jul 18, 2011, at 6:57 PM, Marcus D. Hanwell wrote:

Why specifically non-VTK volume rendering Geoff? If it is the Mac issue I
believe that is close to being resolved. Is this rendering code available? I
had a look on your site and couldn’t find anything. I am certainly
interested in what you have.

I’m just interested in a default dependency-free version. IMHO, it’s a good
thing that Avo has very few dependencies and is easy to compile. I know VTK
is becoming more modular and easier to compile, but it’s still a pretty big
addition. (Consider that I develop on Mac, and while there are Qt binaries,
there are no VTK binaries.)

You might be surprised at just how modular it is, but I see your thinking.
We have also been working on binaries of VTK (which is already much smaller
than Qt in terms of compile time at least). In terms of advanced analysis
features I have been prototyping I would also need solutions for contouring,
3D widgets for selection, slicing, plotting over lines, …

I am always interested in alternative approaches, but would like to make VTK
an optional compile time dependency to integrate these features better in
future for those that want them. As I complete more modularization I will
certainly keep an eye on compile time and test on Mac and Linux very
regularly.

Marcus

Hi all,

On Mon, Jul 18, 2011 at 6:57 PM, Marcus D. Hanwell
mhanwell@gmail.com wrote:

On Thu, Jul 14, 2011 at 1:24 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

A while ago I asked about the prospect for volume rendering (and
better-scalable rendering in Avogadro in general). I was told there was a
VTK integration in the works, but I haven’t heard about it since then.
Also, VTK has pretty awful support for volume rendering – it really
wasn’t designed for that.

Well, I think Marcus will have some thoughts on that. VTK now has
GPU-rendered volume rendering. He’s also been thinking for a while about
better scaling rendering, which I think would be delivered in an Avogadro
2.0 effort once we get 1.1/1.2 out the door this summer and fall.

Do you mean the old CPU based volume rendering code? Since VTK 5.6 (with
improvements in the upcoming 5.8) there is a fast volume rendering component
(originally developed for VTKEdge). I have a VTK plugin that uses the volume
rendering in VTK (up on Github), but it is fairly experimental proof of
concept stuff at this stage. We also have a Google Summer of Code student
(David Lonie) working on adding support for rendering chemical structure in
VTK.

I have been working on volume rendering in vtkChemistry for the last
couple weeks, and I’ve put up a blog post with some screenshots here:

I too am interested in seeing an alternative method – the ability to
have multiple rendering backends may be desired for avogadro 2.0. I
would like to see this written into an extension for avogadro 1.x. If
we make these extensions available to users now we may end up getting
some valuable feedback for when we start designing 2.0’s rendering
engine. Having the extensions will also help us identify any potential
issues that may arise while integrating these specific backends.

Dave

So far I’ve been using my own custom tool, an interactive direct volume
renderer that supports large-scale ball and stick vis. Some examples are
here:
http://www.mcs.anl.gov/~knoll/supersoot/supersoot_bas9.png
http://www.mcs.anl.gov/~knoll/supersoot/supersoot_bas7.png

Well, I’d personally love to have non-VTK volumetric rendering.

Why specifically non-VTK volume rendering Geoff? If it is the Mac issue I
believe that is close to being resolved. Is this rendering code available? I
had a look on your site and couldn’t find anything. I am certainly
interested in what you have.

My motivation: my users (and myself) love the Avogadro interface and
would like to use it if possible.

Great to hear!

Seconded - I would like to ensure it remains useful and having input from
you and others helps a lot there.

What would be involved in modifying Avogadro to support an interactive
GPU raycasting rendering backend? I understand this may not replace
rasterization outright (for backwards compatibility and speed reasons), but
for a lot of visualization this would be a huge improvement.

Well, there is already a GLSL extension when available, and much can be
done with this – personally, I’ve been concentrating on building/editing
tools so a

Beyond that, you’d probably need to start on a new Painter class. We’ve
tried to isolate real rendering calls into this class, so the Pov-Ray or
other export methods use custom Painters.

That would be a logical way to go - add a new Painter class. I would love to
discuss this further, and am interested in what you have available.
Thanks,
Marcus

Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide. Store less, Store more with what you own, Move data to
the right place. Try It Now!
http://www.accelacomm.com/jaw/sfnl/114/51427378/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel