[Edu-sig] re: 3d in Python

Dethe Elza delza@blastradius.com
Mon, 28 Apr 2003 09:06:58 -0700


> Textures and transparency have been discussed a lot on the list.  
> David Scherer has explained to
> me at least twice why the transparency issue is a lot more complicated 
> than adding an alpha
> channel to the  glColor calls in the C code.  Depth cuing, or 
> something. I of course don't
> fully get it.

I get how difficult this is.  I still want it.  %-)

> There are, finally, some specific plans to bring VPython forward and 
> add new features.
> I understand the first step will be a port from CXX to Boost.

That's probably a good thing.  If only it was to port it out of C++ to 
C I'd be able to participate more.  Tracing through dozens of C++ files 
to find where a method is implemented is one of my least favorite 
things.

> "Built as part of PyOpenGL" kind of scares me, because it somehow 
> implies to me the possibility
> of losing VPythons immediacy at the interactive prompt.  There is 
> actually *no* windowing code
> necessary in VPython.  sphere() not only creates the sphere, but its 
> display context.  The creation of
> additional objects will proceed on that same display, until a new 
> display window is explicitly created.

Yes, and I'd expect the same behaviour from VPython, whether it was 
part of PyOpenGL or not.  I'd like to see it become part of PyOpenGL in 
part because that is the closest thing to a standard for 3D in Python, 
and gets ported to more platforms (although their support for OS X has 
been lagging, it's still better than VPython's).  VPython could use 
GLUT for its windows by default, eliminating a lot of code overhead in 
the current version, but allow windows to be specified as wxWindows, 
Tkinter, or whatever by overriding the default.

Actually, just making the default windows use GLUT instead of native 
windows would make my life better (without becoming part of PyOpenGL) 
because then I could compile and run VPython on OS X.

And, interestingly enough, your suggestion for driving VPython remotely 
opens up some cool solutions for combining VPython with Tkinter, 
wxWindows, etc.  More on this below.
>
>> Yes, but it would be easier if I had a better idea what you're trying 
>> to accomplish.
>
> Ideally, try before you buy. In some way, shape or form.
>
> For those outside the Python orbit, the the concept of the 
> dependencies of something like VPython seems
> daunting. Seems to me that folks want to understand the functionality 
> beyond what screenshots can provide,
> before they commit to the effort.
>
> Telling them that VPython is "3d for mortals" is one thing.  Showing 
> them, another.

Still not sure what you're looking for, but I'm going to take a stab at 
it anyway.

>> Yes.  Somewhat easier if you use GLUT (a cross-platform windowing 
>> toolkit for OpenGL), but still pretty hairy.  I mentioned 
>> OpenGLContext because it is supposed to be a friendlier environment.  
>> It features windowing using wxWindows, GLUT, Tkinter, etc., for one 
>> thing, and I believe it is object-oriented, for another.  But I 
>> haven't really explored it much.
>
> I had the pleasure of talking with Mike Fletcher, who I think is doing 
> most of the OpenGLContext work, at PyCon.
>
> But even before OpenGLContext, there was a pre-built Tkinter default 
> display context, that provided simple mouse interactivity,
> and that became available by a simple import statement.  It is 
> actually a good intro to OOP, as one begins to understand that
> inheriting from and overriding a method or 2 in the default display 
> context is how one draws one's own OpenGL construction.
>
>> Yes, the only reason to use one of those is if it gives you something 
>> you need that you can't get from VPython.   If VPython is sufficient, 
>> but you just want to hook it up to the network, that should be 
>> relatively straightforward.  I'd be happy to help, if you can supply 
>> another level of detail.
>
>
> VPython is sufficient, and will hopefully become *more* sufficient 
> over time.
> What would you suggest as a starting point for some experimentation 
> for a remotely accessed VPython - which something other than a
> telnet type session?
>

Well, I have a demo program for VPython, a collection of shapes that 
show off vertices, edges, and faces for polyhedra and spirals.  It was 
getting too big, and some of the shapes take a long time to load, so I 
added a buttload of command-line flags.  Another approach would be to 
add a control window with checkboxes and lists to select aspects of the 
demo, but I didn't really want to take that on in the context of 
VPython.  Your question gave me an "Aha!" moment, because if I wire the 
VPython demo up to XML-RPC (or any other RPC-like mechanism), then I 
can drive the demo from Tkinter, or a web page, or command-line access 
to the running program.  So I'm going to try that.

I haven't had a running VPython for some time, since my hard drive 
crashed a few months ago and I've been reluctant to install Fink and 
all the other cruft needed to get VPython running on OS X under X 
Windows.  But I'll spend some time today to get it running, polish up 
the demo (the code needs a bit of TLC), and wire up some remote 
features.   I should have something to show by the end of the week.

Does that sound anything like what you're looking for?

> Art

--Dethe