Dethe asks:
Is there any reason you can't drive VPython with XML-RPC? Why do you need SVG?
That's really the question I am tryin to get to - is that a possiblity worth investigating. VPython is all the 3d functionality I really require - though there is always a wish list. But XML-RPC is little more than an acronym to me at this point. *If I knew, or at least had reason to believe, that I could in fact drive VPython remotely with XML-RPC, I'd dig in. Can I take you post as an opinion that there is something to be done along these lines? Can you describe how it might be configured/architected - in very, very broad terms? Most of the other tools you refer to, I am familiar with. It was actually through PyOpenGL that I became aware of and involved with using Python. My interest was in learning to work with the OpenGL API without wading through all kinds of windowing APIs to get there. The insanity one needs to go through to get a Windows window prepared for an OpenGL dot, is almost funny. Anti-intuitive is an understatment. The code, to me, looks like a random letter generator at work. Most of the other apps and APIs you reference are overkill for my needs. VTK is awesome, but considerably more than I require. Art *
Arthur wrote:
Dethe asks:
Is there any reason you can't drive VPython with XML-RPC? Why do you need SVG?
That's really the question I am tryin to get to - is that a possiblity worth investigating. VPython is all the 3d functionality I really require - though there is always a wish list.
Yes, my wish list for VPython is: * Runs native on OS X (instead of in X Windows) * Transparency (alpha channel) * Textures * Built as part of PyOpenGL, so I can embed it in wxWindows, GLUT, etc.
But XML-RPC is little more than an acronym to me at this point. *If I knew, or at least had reason to believe, that I could in fact drive VPython remotely with XML-RPC, I'd dig in.
XML-RPC is just one of a plethora of ways to connect programs over the net. There's a full-featured toolkit for building network-savvy programs in Python, called Twisted[1], but it may be overkill for what you want. XML-RPC is pretty simple, and you don't have to know much to use it. There was even a new version released today[2] which is supposed to be 10 times faster (implemented in C, with Python bindings).
Can I take you post as an opinion that there is something to be done along these lines?
I can't think of a reason why not.
Can you describe how it might be configured/architected - in very, very broad terms?
Yes, but it would be easier if I had a better idea what you're trying to accomplish.
Most of the other tools you refer to, I am familiar with. It was actually through PyOpenGL that I became aware of and involved with using Python. My interest was in learning to work with the OpenGL API without wading through all kinds of windowing APIs to get there. The insanity one needs to go through to get a Windows window prepared for an OpenGL dot, is almost funny. Anti-intuitive is an understatment.
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.
The code, to me, looks like a random letter generator at work. Most of the other apps and APIs you reference are overkill for my needs. VTK is awesome, but considerably more than I require.
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.
Art
[1] Twisted Network Framework http://www.twistedmatrix.com/ [2] Py-xmlrpc 0.8.8.3 released http://sourceforge.net/forum/forum.php?forum_id=270940 --Dethe
Dethe Elza wrote:
Yes, my wish list for VPython is: * Runs native on OS X (instead of in X Windows) * Transparency (alpha channel) * Textures * Built as part of PyOpenGL, so I can embed it in wxWindows, GLUT, etc.
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. 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. "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, 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.
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? Art
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
Hi all, Regarding "interactive" VPython on the web, this wouldn't be too hard with a Zope product -- or even just an external method: o HTML form to enter VPython code, and an Image which represents the result. o Type a line of code/VPython-command at the end of the script window. Press a "submit" button. o After a few seconds, get the same form back, with the extra command and the updated image. o Repeat. Naturally, you could add features to make it play back in a less interactive way, a palette to express common function calls etc (i.e. you push the button and the function is typed into the window -- using Javascript -- to remind you of what the syntax looks like), and so on. What it would do is create a browser-based interface to VPython so the user doesn't have to have it installed on their machine. The downside of course, is that you (whoever's running the server) have to pay for all the CPU cycles involved and the bandwidth used is pretty high (because you ship a different image to the browser after every step). So a *good* design would probably consider the overload failure mode you want to see (i.e. what your server should do if there are too many people using it). It might not matter in an academic setting, though (plenty of CPU, large bandwidth, few users). Will VPython run with Python 2.1.3? If it requires 2.2, this would be just a bit harder with the current Zope releases, since AFAIK Zope still needs 2.1. Also, you need to be able to render to an image (i.e. use VPython in a "batch mode") rather than the screen. Does that make sense? Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Dethe writes -
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.
Can't speak to C vs. C++. What I am aeware of is the following: I believe the VPython project has some funding, and there is at least one student proficient in C++ actively focused on it. There is another student, I believe, in New Zealand, who is working on extending it, in interesting ways (it sounds like), I believe as part of some thesis work. He has not released code yet. I think he feels constrained until either his thesis work is complete and accepted, or until he gets some necessary premissions from his institution. But he expects to be able to do so at some point. Back to C vs C++. It does seem to me that if ported as a pure C extension, there would be the possibility of VPython eventually included in the core distro. Were it not for its semi-dependency on Numeric, I would be lobbying for that direction. But I wouldn't be surprised to see some multi-dimensional array capabilities in the core distribution in the not too distant future, so that a VPython in the core distribution could be a real possiblity. As a bonus, the possbility could give me something new to fight with Guido about. ;) Are you on the vpython-users list? Things are pretty much in a kicking around ideas stage. And you're sugestions - a pure C extension, "plays better" with PyOpenGL - seem consistent with ideas that David Scherer has put out there. Though it doesn't seem David is in a position to devote energies to implementation work. And as a practical matter, those who are, seem to be more C++ than C folks. Though that issue has not been addressed head-on as far as I am aware. The slated port to Boost is partly my doing, only in the sense that I pointed out that Paul Dubois, the CXX develper, himself points to Boost as a better alternative for new projects than his CXX library. And one of the goals of the port is not just to go from CXX to Boost, but to simplify and "dequirkify" the code some - making it more realistic for the project to go forward as collaberative, participatory Open Source. It also seems like it is going to be necessary to transition from Numeric to Numarray, and from gtkglarea (providing the OpenGL context for GTK, on Linux) to another library which is superceding it (this, again, being the general recommendation of the gtkglarea developer himself). (Aha, GLUT, he says) So there is much to be done just to stay even, in some sense. But I am getting confident that more than that will get accomplished.
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.
Again, please jump in on the list. There is more flexiblity in thinking there than had been. Though, prelimininarily, I would probably be on the side of "plays better" with PyOpenGL, rather than "become part of PyOpenGL". And that is probably a more realistic shorter term goal. Is the fact that PyOpenGL Swig, and VPython CXX, moving, it looks like, to Boost, an impediment to even a "plays better" status?
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.
There are a number of distribution semi-nightmares arising out of the different windowing dependecies under Windows and under Linux. On the other hand GLUT doesn't seem to be part of the core Linux distros, nor part of Windows - so its does present something of a distribution problem. I know Bruce Sherwood is trying to keep the distribution as simple as possible, but fighting something of an uphill battle in any case due to shifting sands. And since there doesn't, at the moment seem to be any really good and easy solution, maybe the GLUT solution is the lesser of "evils". And when one is talking aobut education and about graphics, it does seem unwise to short shrift Mac. So, yes, it seems to me like it should be brought up. I can do it, but you can do it with more authority. In fact maybe the simplest way to bring it up is to copy vython-users on this exchange. What do you think?
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?
Sounds delicious! Art
Arthur wrote:
Dethe writes -
...
Are you on the vpython-users list? Things are pretty much in a kicking around ideas stage. And you're sugestions - a pure C extension, "plays better" with PyOpenGL - seem consistent with ideas that David Scherer has put out there. Though it doesn't seem David is in a position to devote energies to implementation work. And as a practical matter, those who are, seem to be more C++ than C folks. Though that issue has not been addressed head-on as far as I am aware.
I'm somewhat surprised by this ("playing better") assumption. OpenGL itself should, in general, operate properly without any significant problems based on whether a C++ or C extension is calling it (basically if you can get the extension to load in Python you should be fine). PyOpenGL is programmed in C, of course, but unless you're actually trying to integrate into PyOpenGL itself (why?), or you're using, for instance C++ arrays/vectors or similar data structures instead of Numpy arrays (and passing them to PyOpenGL), it doesn't seem like it would be a problem (the OpenGL layer doesn't care how it's called, and the Python layer doesn't really care either). Is there some history of C++ extensions causing problems with PyOpenGL?
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.
Didn't know we were lagging, have been hearing a deafening silence from the Mac peoples regarding whether the current CVS version builds & runs without problems <shrug> *I* don't have one of those nice titanium powerbooks on which to test it ;) .
Again, please jump in on the list. There is more flexiblity in thinking there than had been. Though, prelimininarily, I would probably be on the side of "plays better" with PyOpenGL, rather than "become part of PyOpenGL". And that is probably a more realistic shorter term goal.
Don't know where the flexibility is (can't be PyOpenGL, I've been there for 5? years (eek!) or so, and you know how pig-headed I am ;) ). I am certainly open to changes required to support compatibility, but to be quite frank, there is too much stuff in the PyOpenGL project as it is (really if OpenGLContext were not the only significant source of tests I have (and my own project so I can add to it) it would probably be broken out, (and GLE is already suffering from bit-rot due to lack of general interest AFAICS)). PyOpenGL has the equivalent of .2 total active developers/administrators (my own time shared across numbers of projects, plus a little bit of Rene's time when he's able (though he did a considerable swack when he first came on board, he seems to have been hijacked by some project or another)). Unless that situation changes (and it looks like I have a stable lead developer), I just don't have the resources to integrate and support another project. Of course, suitors with trunks full of developers are more warmly received ;) :) . That said, marketing is more subtle thing than merely living in the same project space on SourceForge. There's no reason the PyOpenGL web site can't be pointing to other 3D Python projects, particularly those which "play well" with us ;) . BTW, I'm considering doing a "3D Sumo" distribution for OpenGLContext (w/ mxTextTools + SimpleParse + Numpy + PyOpenGL + PIL + (OpenGL + GLUT&GLE)), this would be a piece-wise installer exe for windows, and a mega-RPM-set for Linux. Still not sure how necessary it is, so still considering.
Is the fact that PyOpenGL Swig, and VPython CXX, moving, it looks like, to Boost, an impediment to even a "plays better" status?
See my note above regarding playing better. I have not examined VPython's architecture (yes, I know, bad Mikey), but the Python and OpenGL levels are fairly generic in PyOpenGL, they use regular pointers to Numeric arrays for most things which are not already built-in Python types. There might be some problems with, for instance callback formats, but the PyOpenGL stuff just takes callable python objects, so as long as the python level is used from VPython I would think it would be fine unless shown otherwise :) .
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.
There are a number of distribution semi-nightmares arising out of the different windowing dependecies under Windows and under Linux. On the other hand GLUT doesn't seem to be part of the core Linux distros, nor part of Windows - so its does present something of a distribution problem. I know Bruce Sherwood is trying to keep the distribution as simple as possible, but fighting something of an uphill battle in any case due to shifting sands. And since there doesn't, at the moment seem to be any really good and easy solution, maybe the GLUT solution is the lesser of "evils". And when one is talking aobut education and about graphics, it does seem unwise to short shrift Mac. So, yes, it seems to me like it should be brought up. I can do it, but you can do it with more authority.
In fact maybe the simplest way to bring it up is to copy vython-users on this exchange.
What do you think?
This may be an inappropriate suggestion, facing the same basic problems as the GLUT one, but the PyGame folks do a fairly good job of providing an OpenGL context (not to mention lots of other facilities). They also give you complete control over the mainloop. One downside, of course, is that they have no "WIMP" interface support, so your students have to write the entire interface code instead of being able to dump GTK/Tkinter/wxPython buttons onto a window to control their applications. Not sure if the PyUI project ever got far enough to be useful that way. The upside is that students are often more excited to work in a "game"-oriented environment, and there are already Python educational initiatives using PyGame (Pygsear, if I recall correctly). Okay, enough of my blathering. Enjoy all, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/
Dethe Elza wrote:
Arthur wrote:
...
Most of the other tools you refer to, I am familiar with. It was actually through PyOpenGL that I became aware of and involved with using Python. My interest was in learning to work with the OpenGL API without wading through all kinds of windowing APIs to get there. The insanity one needs to go through to get a Windows window prepared for an OpenGL dot, is almost funny. Anti-intuitive is an understatment.
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.
It is (some might say pathologically) object-oriented (it includes, for instance, a property-based modeling of VRML97 scenegraphs, which were in turn model on Open Inventor). It does try to be a somewhat friendlier environment *for OpenGL*, though it needs considerably more documentation to actually fulfill that goal. It is, IMO, certainly easier than raw OpenGL for many common tasks that a student wants to learn to do with OpenGL. It's not, however, trying to create "3-D graphics for everyone". It's raison d'etre (sorry to the Francophones, don't feel like finding accents at the moment) is to provide OpenGL sample code, and to make it possible to write fairly readily understood "lesson modules" for teaching OpenGL. The system takes care of the "normal" OpenGL bookkeeping, letting you (hopefully) focus on teaching the actual technique in which you are interested. For simple techniques (the kind of things you are likely to see in an introduction to computer graphics programming course, I would imagine, textures, transparency, NURBs, those kinds of things), it works quite nicely IMO. When you get into more complex techniques (for example infinite perspective matrices + shadow volumes or the like), it likely becomes a wash for educational purposes. You can point at the package or module that implements the difference from the "normal" rendering procedure, but that presupposes that the user understands that rendering procedure (there is documentation, but it is written informally, and is likely to lose a student in its current form). Enjoy, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/
participants (4)
-
Arthur -
Dethe Elza -
Mike C. Fletcher -
Terry Hancock