visualpython-users

[Visualpython-users] New stuff

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

Dave Scherer just implemented some useful new features in Visual:

display.lights and display.ambient let you control lighting of the scene.

display.objects is a list of all the currently visible objects in the
scene. You can loop through them to make them all red, for example.

object.__class__ tells you what kind of object it is.

object.__members__ gives you a list of all the attributes of this object.

The new documentation includes instructions on how to use these new
features.

You can get the new features for Windows at the usual place:

	http://cil.andrew.cmu.edu/projects/visual

First you have to install Python 2.0 (see directions on the web site). Our
experience so far is that uninstalling Python 1.5.2 on Windows and
installing Python 2.0 is utterly painless. As a result, we will only be
supporting Visual on Python 2.0.

No Linux or Mac versions yet.

Bruce Sherwood

P.S. Thanks, Dave!

[Visualpython-users] Red Hat fix

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

The VPython web site (http://cil.andrew.cmu.edu/projects/visual) now has
the details on the Red Hat fix contributed by Roger Fearick, including the
recompiled file that you need.

Bruce

[Visualpython-users] Correction

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

I've corrected a mistake in the download package to accompany Python 2.0.
If you already installed that zip file, you need to copy the
C:\Python20\Idle folder into C:\Python20\Tools to invoke the enhanced
version of Idle.

Bruce

Re: [Visualpython-users] VPython Compatability

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

--On Thursday, November 23, 2000, 10:30 PM +0000 Do...@ao... wrote:

> Are there any other releases / flavors of Python that VPYTHON is
> compatible  with? (eg Python 2.0, Stackless Python, Vyper etc)
> 
> Compatible in the sense that you can have them on the same machine as 
> VPython, not neccessarily at the same time.

Funny you should ask. About one minute before reading your note, I finished
making available a Visual package for Python 2.0 for Windows. See

	http://cil.andrew.cmu.edu/projects/visual

What you do is install regular Python 2.0 (presumably uninstalling other
versions of Python, I would guess, but I'm no expert), then unzip a zip
file that adds Visual, Numeric, the Scherer version of Idle, and
significantly improved documentation (in html rather than pdf format, with
much better indexing).

I went ahead and made the change to visual.graph to change the names gvbar
-> gvbars, ghbar -> ghbars, gdot -> gdots, and updated the demo programs
that use graphs (graphtest.py and gas.py). The graph module will still
accept the older names but prints a warning message that the names should
be changed. But let me know if you object to this change or have a better
idea for the names.

Still available on the web site is the old Python 1.5.2 stuff (1.5.2
modified to bind Tcl into it), but I would encourage people to move up to
Python 2.0. Ruth Chabay and I have been using Python 2.0 on Windows for a
while now and have seen no problems.

Bruce Sherwood

[Visualpython-users] VPython Compatability

[<Do...@ao...>]

Are there any other releases / flavors of Python that VPYTHON is compatible 
with? (eg Python 2.0, Stackless Python, Vyper etc)

Compatible in the sense that you can have them on the same machine as 
VPython, not neccessarily at the same time.

Dumb-questions-r-me

[Visualpython-users] Graph syntax

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

Some of you may have invoked visual.graph to plot 2D graphs of functions
and data with autoscaling. Our own physics students have been using it all
this semester, mainly with gcurve (which draws lines between the data
points). This week for the first time they used the vertical-bar option,
and we found that the names of some of the graphics objects in the package
should probably be changed, as proposed here:

	gvbar -> gvbars (or possibly gvbargraph)
	ghbar -> ghbars (or possibly ghbargraph)
	gdot -> gdots (or possibly gdotgraph or gscatter)

The way these are used is shown in the following example:

	mybars = gvbar(color=color.red, delta=0.3) 
	for x in range(100):
		mybars.plot(pos=(x,y))

The mild problem we encountered was with the name in the singular (gvbar),
there was a tendency to think it makes just one vertical bar, so students
put both the gvbar constructor and the plot option in the loop, which is
inefficient. It seems plausible that using a plural name (gvbars) or a name
such as gvbargraph the intent would be clearer. I prefer the shorter
version gvbars to gvbargraph.

Any comments? I'd like to make this change right away in the context of
making a major release of VPython that is compatible with Python 2.0 and
which has much improved documentation for Visual. I don't imagine that
there are very many programs in existence that use gvbar.

Bruce Sherwood

RE: [Visualpython-users] vpython and wxPython

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

> if I try to run the program in the visualpython-IDLE I get the following
> in the output window:
>
> Visual-2000-06-10
> Traceback (innermost last)
>   File "c:\python\programs\wxpy_test\test.py", line 2, in ?
>     from wxPython.wx import *
> SystemError: bad argument to internal function

I don't have an explanation, but I've never tried to use wxPython from IDLE.
If you want to try tracking down the problem, I would start by:

1) Removing the visual code from the example, so that only IDLE and wxPython
are involved

2) Look at loader.py and Remote.py, which make up the part of IDLE that runs
in the same process as your program.  Whatever conflicts with wxPython must
be somewhere in there.

3) Try importing wxPython from inside a user thread (but not using IDLE) to
see if the problem might be related to the loader's use of threading (your
program is not executed in the main thread when it executes under IDLE).

Dave

Re: [Visualpython-users] deleting objects

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

--On Thursday, November 23, 2000, 5:31 PM +0100 Rochus Schmid
<roc...@ch...> wrote:

> is there a way to delete a vpython object?
> I know that I can make it invisible.
> 
> but if I say:
> 
> s=sphere()
> del(s)
> 
> the sphere remains (I just lost the python object to tweak it :-)

The only way to make a Visual object disappear is to make it invisible. If
you in addition do del(s) as you say, or simply assign something else to s,
it is my understanding that eventually Python will garbage collect the
object structure. So the rule is, make the object invisible, then use the
name for something else (or use del).

> in my case a molecule is displayed along a reaction coordinate. the
> number of bonds (=cylinders) varies with the geometry.
> soemtimes a bond may appear and vanish a couple of frames later.
> it would be a lot of bookkeeping to decide whether there are still
> invisible objects to switch on or a new cylinder must be created.
> I could just generate a lot of cylinders and switch them to invisible
> but that seems not very elegant to me?

You need not do any special bookkeeping. Just make the object invisible
before deleting or reusing the name. I guess the documentation should
explain that del doesn't make an object invisible, just inaccessible.

Bruce Sherwood

[Visualpython-users] deleting objects

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

Hi,

sorry to bug you with one more question:

is there a way to delete a vpython object?
I know that I can make it invisible.

but if I say:

s=sphere()
del(s)

the sphere remains (I just lost the python object to tweak it :-)

in my case a molecule is displayed along a reaction coordinate. the
number of bonds (=cylinders) varies with the geometry.
soemtimes a bond may appear and vanish a couple of frames later.
it would be a lot of bookkeeping to decide whether there are still
invisible objects to switch on or a new cylinder must be created.
I could just generate a lot of cylinders and switch them to invisible
but that seems not very elegant to me?
did I miss something? couldnt find anything in the docs, nor looking at
the functions in the visual module or in the demos.

what can I do?

all the best,


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

[Visualpython-users] vpython and wxPython

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

Hi,

Am I doing something wrong or is there a problem using wxPython from the
visualpython-Idle ?
(on w98!)

I tried the following to test it:
**************
from visual import *
from wxPython.wx import *

class MyApp(wxApp):
    def OnInit(self):
        frame = wxFrame(NULL, -1, "test")
        frame.Show(true)
        self.SetTopWindow(frame)
        s = sphere()
        return true

app = MyApp(0)
app.MainLoop()

*******************
if I try to run the program in the visualpython-IDLE I get the following
in the output window:

Visual-2000-06-10
Traceback (innermost last)
  File "c:\python\programs\wxpy_test\test.py", line 2, in ?
    from wxPython.wx import *
SystemError: bad argument to internal function

Program stopped.


However, when I just save the program as test.py from IDLE and start it
directly I get the wxWindow and the vpython window with a nifty white
sphere.

(I used tkinter in my python stuff but heard so many good things about
wxPython (and the demos *are* cool) that I wanted to try/learn it).
Well, I could just *not* use IDLE or use it simply as a text editor ...
I am just curious.

cheers,

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] Red Hat Linux

[Stephen W. <sw...@ga...>]

This was pretty helpful with one exception:  I haven't figured out how to
use CVS to check out the latest VPython sources.  What module name should
I use in the 'cvs co' to get the entire tree intact?  I am a CVS novice
but have in the past been able to get the Lesstif and Samba sources using
it, so I know more or less how it works.

--
Stephen Walton, Professor of Physics and Astronomy,
California State University, Northridge
ste...@cs...

On Tue, 21 Nov 2000, Bruce Sherwood wrote:

> Roger Fearick sent this interesting and informative note and asked me to
> forward it to the VPythyon user list, which had forgotten to do. Thanks
> much for the information, Roger, both on Red Hat and on your use of VPython
> in physics education. We will put your Red Hat information on the VPython
> web site.

[Visualpython-users] Red Hat Linux

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

Roger Fearick sent this interesting and informative note and asked me to
forward it to the VPythyon user list, which had forgotten to do. Thanks
much for the information, Roger, both on Red Hat and on your use of VPython
in physics education. We will put your Red Hat information on the VPython
web site.

---------- Forwarded Message ----------
Date: Tuesday, November 21, 2000, 3:16 PM +0000
From: Roger Fearick <FE...@ph...>
To: Bruce Sherwood <ba...@an...>
Subject: Re: [Visualpython-users] Red Hat Linux

> Hi Bruce,
> 
>> Thanks much for the file. Could you possibly write a brief paragraph
>> aimed at Red Hat users, to accompany making the file available on our
>> web site? Not being a Linux user, I couldn't follow your instructions
>> well enough to know exactly what to say. Thanks.
> 
> How I got VPython working on Redhat 6.2
> =======================================
> 
> There seem to be two problems:
> 
> 1) The cvisualmodule.so supplied in the VPython linux distribution
> makes calls to a version of a C++ dynamic library that is not
> compatible with the version on RH 6.2.
> 
> Solution: I have recompiled cvisualmodule.so: just copy the recompiled
> version over the original.
> 
> 2) There seems to be some thread-related bug in RH6.2. I couldn't even
> get the thread examples in /usr/doc/glibc-2.1.3 to run.
> 
> Solution: I applied two updates (probably only the second is needed,
> but the first is worthwhile anyway):
>     a) I updated the c library.
>        See http://www.redhat.com/support/errata/RHSA-2000-057-04.html
>        for details and instructions.
>        Probably only the file
>         ftp://updates.redhat.com/6.2/i386/glibc-2.1.3-21.i386.rpm
>        is needed: it can be installed by running rpm -Fvh [filename]
>        as superuser.
>     b) I updated the kernel to 2.2.16.
>        This is probably the essental step.
>        See http://www.redhat.com/support/errata/RHSA-2000-037-05.html
>        for details and instructions.
>        Read these carefully if you haven't done this before !!!
> 
> After this, VPython ran.
> 
> 
> 
>> P.S. I see you are in physics. What is your (physics?) interest in
>> VPython?
> 
> I've been running an introductory course on computational physics for
> our senior students. There is usually a wide range of programming
> skills to deal with (down to 'never programmed before')., and I
> decided this year to try Python as the 'language of record' in which
> I gave my examples. (Students are free to use other languages if they
> are more familiar with them.)
> I wanted something that would be freely available to students so that
> they could install software on their own computers. I have previously
> used Lahey ELF90, a Fortran 90 subset, but the freely downloadable
> version of this was discontinued in the middle of last year, so this
> year I tried Python (using Numeric of course).
> 
> I have been pleasantly suprised how easily my F90 code has translated
> into Python, slices and all. The students have generally found it
> easy to program in Python (after the initial "Python? What...?").
> 
> Graphics has been a bit of a problem, but graphs can be drawn with
> dislin, and Tkinter can be used although it requires constructing
> a GUI application to do anything, so it's rather messy.
> But it's nice to have some animation, so I showed them how to collide
> a wavepacket with a barrier in Tkinter.
> 
> VPython on the other hand makes this sort of thing essentially
> trivial. It is really an incredible package which shows how graphics
> should work in a threaded environment. So congratulations and thank
> you for making it available.
> 
> It arrived a bit late to use in this year's course, but I'm sure that
> I will make use of it next year (when the course is moved down to a
> more junior level). Nevertheless I've had fun animating the numeric
> integration of the solar system, pulses on a string, etc.
> 
> I'm sure it will also make an appearance in my first-year mechanics
> lectures next year: I can see many little programs along the line of
> your cross-product demo being useful to illustrate things.
> 
> Roger.
> 
> --
> Roger Fearick
> Department of Physics
> University of Cape Town
> 

---------- End Forwarded Message ----------

RE: [Visualpython-users] Patch for limiting zoom in vpython

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

Right. Got it. Makes sense.

--On Monday, November 20, 2000, 8:52 AM -0500 David Scherer
<dsc...@CM...> wrote:

> Definitely not!  To make any sense of the camera position you need to know
> horrible things like the field of view angle and the aspect ratio of the
> window, not to mention some trig.  Normally you control scale with
> scene.range, right?
> 
> sphere(radius = 50)
> scene.range = 50
> 
>> I'm not sure I understand what the
>> significance
>> would be of minimum and maximum ranges, which sound like cubes or boxes
>> to me.
> 
> These would place limits on how small or large the *effective* scene.range
> could get in response to manual control.

[Visualpython-users] Fwd: Noising a scene

[<Do...@ao...>]

RE: [Visualpython-users] Patch for limiting zoom in vpython

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

> I agree that control of manual_scale doesn't sound like a good idea. Since
> the standard Visual interface includes rotation around the center of the
> scene, would it make sense just to give minimum and maximum distances for
> the camera from the center?

Definitely not!  To make any sense of the camera position you need to know
horrible things like the field of view angle and the aspect ratio of the
window, not to mention some trig.  Normally you control scale with
scene.range, right?

sphere(radius = 50)
scene.range = 50

> I'm not sure I understand what the
> significance
> would be of minimum and maximum ranges, which sound like cubes or boxes to
> me.

These would place limits on how small or large the *effective* scene.range
could get in response to manual control.

Dave

RE: [Visualpython-users] Patch for limiting zoom in vpython

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

--On Sunday, November 19, 2000, 3:55 PM -0500 David Scherer
<dsc...@CM...> wrote:

> I think both minimum and maximum zoom limits are a good idea, but I'm not
> sure if this is the right interface or not.  An example alternative would
> be minimum and maximum ranges.  What does everyone think?

I agree that control of manual_scale doesn't sound like a good idea. Since
the standard Visual interface includes rotation around the center of the
scene, would it make sense just to give minimum and maximum distances for
the camera from the center? I'm not sure I understand what the significance
would be of minimum and maximum ranges, which sound like cubes or boxes to
me.

Bruce

RE: [Visualpython-users] Patch for limiting zoom in vpython

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

> > Could you please write a sentence or two of documentation? What does a
> > limit of 10.0 mean? Thanks.

> There is a parameter in the gldevice.cpp file named 'manual_scale'.
> There is no documentation for this parameter that I could find -- maybe
> the authors of VPython would like to put in a word. All my patch does is
> set a maximum limit for this parameter.

manual_scale isn't documented because it isn't exposed externally.  A
manual_scale of 10.0 means that scene.range is effectively *divided* by 10.
This is intuitively the same as zooming in by a factor of 10 from the
default provided by autoscale or by scene.range.

I think both minimum and maximum zoom limits are a good idea, but I'm not
sure if this is the right interface or not.  An example alternative would be
minimum and maximum ranges.  What does everyone think?

Dave

Re: [Visualpython-users] Patch for limiting zoom in vpython

[Gavrie P. <ga...@ne...>]

Bruce Sherwood wrote:
> 
> --On Thursday, November 16, 2000, 2:48 PM +0200 Gavrie Philipson
> <ga...@ne...> wrote:
> 
> > The patch adds a new attribute to "display" objects. The attribute is
> > named "zoom_limit", and is a float value.
> > In Python, you can now say: visual.scene.zoom_limit = 10.0, for example.
> 
> Could you please write a sentence or two of documentation? What does a
> limit of 10.0 mean? Thanks.

Hi Bruce,

The only documentation needed is the line you quoted above -- the change
is pretty small.
But, some more explanation:

There is a parameter in the gldevice.cpp file named 'manual_scale'.
There is no documentation for this parameter that I could find -- maybe
the authors of VPython would like to put in a word. All my patch does is
set a maximum limit for this parameter. 
A limit if 10.0 means that the maximum value this manul_scale parameter
can attain is 10.0.
I can't explain the exact physical meaning of this parameter.

Cheers,

Gavrie.

-- 
Gavrie Philipson
Netmor Applied Modeling Research Ltd.

Re: [Visualpython-users] Patch for limiting zoom in vpython

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

--On Thursday, November 16, 2000, 2:48 PM +0200 Gavrie Philipson
<ga...@ne...> wrote:

> The patch adds a new attribute to "display" objects. The attribute is
> named "zoom_limit", and is a float value.
> In Python, you can now say: visual.scene.zoom_limit = 10.0, for example.

Could you please write a sentence or two of documentation? What does a
limit of 10.0 mean? Thanks.

Bruce Sherwood

[Visualpython-users] Patch for limiting zoom in vpython

[Gavrie P. <ga...@ne...>]

Hi,

I needed a feature in VPython that would let me limit the amount that
the user can zoom in with the mouse. 
After not finding a way of doing this, I have written a small patch to
enable it.
The patch adds a new attribute to "display" objects. The attribute is
named "zoom_limit", and is a float value.
In Python, you can now say: visual.scene.zoom_limit = 10.0, for example.

The patch is attached.
If others find it useful, maybe it can be added to the CVS?

Gavrie.

-- 
Gavrie Philipson
Netmor Applied Modeling Research Ltd.

Re: [Visualpython-users] Format Problem

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

David Porter reported trouble with this print statement:

> print "k = %10.5f w = %10.5f Q = %10.5f wh = %10.5f\n" % (k, w, Q, wh)

This works for me (Python 2.0 on Windows). I find the start of your error
report puzzling:

Exception in Tkinter callback
Traceback (innermost last):
   File "c:\Python\Lib\lib-tk\Tkinter.py", line 764, in __call__
     return apply(self.func, args)

Why would you be getting a report from Tkinter? What is the full context of
your program?

Bruce Sherwood

[Visualpython-users] Format Problem

[David P. <dp...@dr...>]

Hello
	I believe this is really a python problem as compared to a visual python problem but I hope someone out there may know the answer. I am trying to send formated output to the screen and to a file.  

print "k = %10.5f w = %10.5f Q = %10.5f wh = %10.5f\n" % (k, w, Q, wh)

fprev.write ('k = %10.5f w = %10.5f Q = %10.5f wh = %10.5f\n' % (k, w, Q, wh))

The variables k, w, Q, and wh are real floating point numbers. If I execute an unformated print statement before trying to execute the formated statement, the values are what I expected, (k = 0.001, w = 1.0, Q = 1.0e2, wh = 0.0) The formated statements work in a different version of the program. When I moved the statements into a function the following error occured.

Exception in Tkinter callback
Traceback (innermost last):
   File "c:\Python\Lib\lib-tk\Tkinter.py", line 764, in __call__
     return apply(self.func, args)
   File "c:\python\programs\graph1.py", line 152, in run
     print " k = %10.5f w = %10.5f Q = %10.5f wh = %10.5f\n" % (k, w, Q, wh)
TypeError: illegal argument type for built-in operation

Any suggestions will be appreciated.
	Thanks
	Dave Porter

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

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

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