visualpython-users

[Visualpython-users] Re: VPython

[Bruce S. <ba...@an...>]

--On Monday, November 13, 2000, 6:21 PM +0100 Rochus Schmid
<roc...@ch...> wrote:

> Dear Bruce,
> 
> I use Python (+NumPy + own C-extensions) for a while now in a self
> developed quantum chemistry code. This code is based on some (Wave)fcts
> discretized on even spaced cartesian grids in real space. Basically for
> debugging and getting a clue of what is going on I wrote a simple
> "grid-viewer" using PyOpenGL (and always hated to fiddle with the
> Togl.so and stuff).
> In this context I always wanted to write a simple molecular viewer and
> orbital analysis tool in python (thought about PyOpenGL maybe together
> with wxPython etc. etc.).
> 
> There are others who have done something like that (PyMol from Warren
> Delano or PVM from Michael Sanner at Scripps) but they are very focused
> on visualizing protein structers and large organic molecules (with fancy
> display stiles etc etc.)
> However I want it much more simple.
> Balls and Spheres (maybe some labels and arrows) should do it as long as
> I can click and select with my mouse.
> It seems to me that VPython is just what I was looking for.
> I will have to get my hands dirty and see how far I get.
> 
> From looking at the pdf-docs and the demos VPython seems quite perfect
> for me (especially the seperate thread for the viewer is great).
> One question:
> from the demos it seems that rotating the scene means rotating the
> lighting with it. how could I trackball rotate an object without
> rotating the light ... well, I guess that means not moving the camera
> around but really rotating the object (especiall a collection of
> objects?)

No, when you trackball rotate, you rotate the camera, not the scene, so the
lighting stays where it was. (That is, rotate by 180 degrees and you see
the shadowed side of the scene.) At the moment there is no control over the
positioning of the lighting.

As you say, if you want the objects to rotate separately from the lighting,
you can rotate the objects. In fact, you could put all of the individual
objects into a Visual "frame" and just rotate that one composite object.

In the demo "stonehenge.py" is an example of continuously changing the
camera position and angle to allow free roaming through the scene.

> 
> and (forgive me ;-) one more:
> I just dreamt about a posiblility to simultaneously "show" the real
> space grid along with the molecule. that probably means to first get an
> isosurface with a "marching cube" algorithm or something like that and
> to render that. Did you and the other developers of VPython ever think
> about something like that? It looks like you focused a lot on
> visualizing physics with VPython and that might be a more common taks.
> The alternative is to have some kind of "mesh"-object (From playing with
> convex it seems to me that this is not really what I need).

Dave Scherer has from time to time expressed interest in implementing some
kind of grid or height field. One hopes that he or someone else will do
this eventually.

> I read a quastion in the archives about the accessability of "raw"
> OpenGL calls inside VPython.
> I do not know if one could generate a GL_LIST using PYOpenGL and hand
> this over to VPython (Or is that stupid?)

I don't know enough to comment on this.

> If the "mesh"-object would exist (say an array for surface points in the
> right order and some normal vectors or so) one could calculate this
> array seperate from VPython in NumPy or alternatively in some other
> C/C++-module.
> But I have to say, that I realized that I would probably not be able to
> extand VPYthons Objects cause I am probably simply too stupid for C++
> and looking at the CXX stuff just killed me :-)
> ooops, that is tough.
> So simple C extensions and NumPy and a couple of PyOpenGL calls is ok
> .... but the convex.cpp .... too much for me.
> 
> I am not quite sure if I could clarify what I wanted to say. But thanks
> for your patience reading up to this point.
> Even if the "grid-visualization" does not work VPYthon as awesome.
> Thanks.

Glad you like it!

> 
> Greetings from sunny Munich,

I very much enjoyed visiting Munich for a week in 1960, but I haven't been
back since.

> 
> 
> Rochus
> 
> 
> --
> 
> Dr. Rochus Schmid
> Technische Universität München
> Lehrstuhl f. Anorganische Chemie
> Lichtenbergstrasse 4, 85747 Garching
> 
> Tel.    ++49 89 2891 3174
> Fax.    ++49 89 2891 3473
> Email   roc...@ch...
> 
> 

RE: [Visualpython-users] Re: VPython

[David S. <dsc...@cm...>]

> > from the demos it seems that rotating the scene means rotating the
> > lighting with it. how could I trackball rotate an object without
> > rotating the light ... well, I guess that means not moving the camera
> > around but really rotating the object (especiall a collection of
> > objects?)
>
> No, when you trackball rotate, you rotate the camera, not the
> scene, so the
> lighting stays where it was. (That is, rotate by 180 degrees and you see
> the shadowed side of the scene.) At the moment there is no
> control over the
> positioning of the lighting.

You are both describing the same thing, in different reference frames.  Do I
really have to explain this to physics professors?  :)

> As you say, if you want the objects to rotate separately from the
> lighting,
> you can rotate the objects. In fact, you could put all of the individual
> objects into a Visual "frame" and just rotate that one composite object.

Yes, and if you want to control this with the mouse you should be able to
pull that off.  However, by customizing mouse interaction you lose some of
the benefit of background rendering, since if you stop polling the mouse the
interaction will "freeze".

This may be one occasion where hacking cvisual (to do camera-local lighting)
is actually the easiest way to go.

> > I just dreamt about a posiblility to simultaneously "show" the real
> > space grid along with the molecule. that probably means to first get an
> > isosurface with a "marching cube" algorithm or something like that and
> > to render that.

I'm not sure what you mean... are you trying to display

  - a 2D scalar (height) field?
  - a 3D scalar field?
  - a 3D vector field?
  - a plain 3D grid?
  - something else?

> > I read a quastion in the archives about the accessability of "raw"
> > OpenGL calls inside VPython.
> > I do not know if one could generate a GL_LIST using PYOpenGL and hand
> > this over to VPython (Or is that stupid?)

No, it's actually a pretty good idea, and obvious to me only in hindsight :)
Off the top of my head, I think the level of thread safety in the major GL
implementations is good enough to permit building display lists outside the
renderer thread, at least in principle.

The capability doesn't already exist, but I'll seriously consider adding it
if I ever have a free moment.  The tricky part is that VPython mainly avoids
the OpenGL transformation pipeline, since OpenGL uses low-precision math
that causes problems for very large or small quantities.

> > If the "mesh"-object would exist (say an array for surface points in the
> > right order and some normal vectors or so) one could calculate this
> > array seperate from VPython in NumPy or alternatively in some other
> > C/C++-module.

Mesh is something I *want* to get implemented, because it's a superset of
*lots* of other useful things (height field, extrusion, surface of
revolution).

Some time ago someone posted a program to this list that implemented a mesh
using lots of little convex objects.  That approach is far from ideal in
performance terms, but it might work for you in a pinch.

> > But I have to say, that I realized that I would probably not be able to
> > extand VPYthons Objects cause I am probably simply too stupid for C++
> > and looking at the CXX stuff just killed me :-)
> > ooops, that is tough.
> > So simple C extensions and NumPy and a couple of PyOpenGL calls is ok
> > .... but the convex.cpp .... too much for me.

Not every visual primitive is as hard to write as convex, but extending
visual in C++ is definitely rather challenging at the moment.

Dave

Re: [Visualpython-users] Re: VPython

[Rochus S. <roc...@ch...>]

Dear David,

Thanks for your answer. I am definitly no physics professor and I'm willing to
learn from everyone.
(Actually I am what the somewhat anachronistic german academic system calls a
"habilitand". Well, and I am a chemist :-)

David Scherer wrote:

> > > from the demos it seems that rotating the scene means rotating the
> > > lighting with it. how could I trackball rotate an object without
> > > rotating the light ... well, I guess that means not moving the camera
> > > around but really rotating the object (especiall a collection of
> > > objects?)
> >
> > No, when you trackball rotate, you rotate the camera, not the
> > scene, so the
> > lighting stays where it was. (That is, rotate by 180 degrees and you see
> > the shadowed side of the scene.) At the moment there is no
> > control over the
> > positioning of the lighting.
>
> You are both describing the same thing, in different reference frames.  Do I
> really have to explain this to physics professors?  :)
>

What I meant is the following:
what most openGL molecule viewers and eg. as far as I know also VTKPython do (as
default behaviour) is to "move" the light with the camera. that means that the
light shines always from the front and that basically means it looks like you
are *turning* the object around (as if you would hold the molecule with your
hands). So VPython is not doing that which means (at least thats how I "feel"
it) the observer is "flying" around the scenery. In terms of just camera and
object what I said is indeed the same. but with lighting it looks different.
And for fidling with molecules and editing their geometry in 3d I think it is
much more convenient "human-brain-wise" to turn the *object*.


>
> > As you say, if you want the objects to rotate separately from the
> > lighting,
> > you can rotate the objects. In fact, you could put all of the individual
> > objects into a Visual "frame" and just rotate that one composite object.
>
> Yes, and if you want to control this with the mouse you should be able to
> pull that off.  However, by customizing mouse interaction you lose some of
> the benefit of background rendering, since if you stop polling the mouse the
> interaction will "freeze".
>
> This may be one occasion where hacking cvisual (to do camera-local lighting)
> is actually the easiest way to go.
>
>

ah! ok. so I will have to sit down, take the red bible on openGL and figure out
how to position the lighting where the camera is. i'll try my very best.

> > > I just dreamt about a posiblility to simultaneously "show" the real
> > > space grid along with the molecule. that probably means to first get an
> > > isosurface with a "marching cube" algorithm or something like that and
> > > to render that.
>
> I'm not sure what you mean... are you trying to display
>
>   - a 2D scalar (height) field?
>   - a 3D scalar field?
>   - a 3D vector field?
>   - a plain 3D grid?
>   - something else?
>
>

oh you are right ... as I said, just a chemist. apologies.
my wavefunktions or elecron densities are 3D scalar fields on a structured grid
(even spaced cartesian) and what I meant was to generate a iso-surface (polygon
mesh?) from that either directly in VPython or outside and hand it to VPython as
a NumPy array.


> > > I read a quastion in the archives about the accessability of "raw"
> > > OpenGL calls inside VPython.
> > > I do not know if one could generate a GL_LIST using PYOpenGL and hand
> > > this over to VPython (Or is that stupid?)
>
> No, it's actually a pretty good idea, and obvious to me only in hindsight :)
> Off the top of my head, I think the level of thread safety in the major GL
> implementations is good enough to permit building display lists outside the
> renderer thread, at least in principle.
>
> The capability doesn't already exist, but I'll seriously consider adding it
> if I ever have a free moment.  The tricky part is that VPython mainly avoids
> the OpenGL transformation pipeline, since OpenGL uses low-precision math
> that causes problems for very large or small quantities.

The nice thing about using PyOpenGL for my (tiny little "gridviewer" .. at least
it works) was the "one2one" representation of C-calls to OpenGL lib functions.
the awfull part was always the render context (I used the standard Togl
construction of Togl_in_TCl_inPython which is a pain in the ...  )

>
>
> > > If the "mesh"-object would exist (say an array for surface points in the
> > > right order and some normal vectors or so) one could calculate this
> > > array seperate from VPython in NumPy or alternatively in some other
> > > C/C++-module.
>
> Mesh is something I *want* to get implemented, because it's a superset of
> *lots* of other useful things (height field, extrusion, surface of
> revolution).
>
> Some time ago someone posted a program to this list that implemented a mesh
> using lots of little convex objects.  That approach is far from ideal in
> performance terms, but it might work for you in a pinch.
>
> > > But I have to say, that I realized that I would probably not be able to
> > > extand VPYthons Objects cause I am probably simply too stupid for C++
> > > and looking at the CXX stuff just killed me :-)
> > > ooops, that is tough.
> > > So simple C extensions and NumPy and a couple of PyOpenGL calls is ok
> > > .... but the convex.cpp .... too much for me.
>
> Not every visual primitive is as hard to write as convex, but extending
> visual in C++ is definitely rather challenging at the moment.
>

>
> Dave
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> http://lists.sourceforge.net/mailman/listinfo/visualpython-users

yeah. I think it is not the much the OpenGL stuff itself (in either convex.cpp
or sphere.cpp) but how to get info from python level into C++ level.

but to say that: it is wonderfull to play around with VPython and to see obejcts
pop up in the render window and to figure out how to do things "interactively".
I really like it and I will dedicate some spare time to a little
molecule-builder ... I'm curious how far I get.
Thanks for your help again.

greetings,

rochus

--

Dr. Rochus Schmid
Technische Universität München
Lehrstuhl f. Anorganische Chemie
Lichtenbergstrasse 4, 85747 Garching

Tel.    ++49 89 2891 3174
Fax.    ++49 89 2891 3473
Email   roc...@ch...

RE: [Visualpython-users] Re: VPython

[David S. <dsc...@cm...>]

> Thanks for your answer. I am definitly no physics professor and
> I'm willing to learn from everyone.

I was teasing Bruce, who definitely is a physics professor, and who answered
your question by essentially restating what you said.

> In terms of just camera and object what I said is indeed the
> same. but with lighting it looks different.

Either you are "rotating the scene" and the lights rotate with the scene
because they are part of it, or you are "moving the camera" while the scene
and lights stay still.

I agree that in this case the "moving camera" interpretation is more
natural, but I'm not confident that everyone else will agree.

> And for fidling with molecules and editing their geometry in 3d I
> think it is much more convenient "human-brain-wise" to turn the
> *object*.

Fair enough.

> ah! ok. so I will have to sit down, take the red bible on openGL
> and figure out
> how to position the lighting where the camera is. i'll try my very best.

The code you want to modify is in gldevice.cpp.  Look for a line beginning

rView view(wct, display->lights,

Here you can change the lighting to do whatever you want.  I think this
might do what you desire:

lighting new_lights;

// Ambient light 0.2 (this is the normal default)
new_lights.ambient = 0.2;

// Light in the direction of the camera, maximum brightness:
new_lights.L[0] = (cam - display->c_center).norm() * 1.0;

// This light is off:
new_lights.L[1] = Vector( 0, 0, 0 );

// Use new_lights instead of display->lights
rView view(wct, new_lights, ...

> oh you are right ... as I said, just a chemist. apologies.
> my wavefunktions or elecron densities are 3D scalar fields on a
> structured grid
> (even spaced cartesian) and what I meant was to generate a
> iso-surface (polygon
> mesh?) from that either directly in VPython or outside and hand
> it to VPython as
> a NumPy array.

Okay, understood.  If you want the isosurface to be transparent, your best
bet for the moment might just be to draw the grid with curves:

isosurface = calc_isosurface(...)

# isosurface[i,j] = [x y z] position

for i in range(isosurface.shape[0]):
  curve(pos = isosurface[i,:])
for j in range(isosurface.shape[1]):
  curve(pos = isosurface[:,j])

Dave