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