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...