Arthur Siegel writes: --- clip ---
So that I certainly do not want support a Python to POV-RAY, versus PyGeo argument.
BUT - (you knew one was coming)
What hasn't been emphasized in the discussion so far is the PyGeo is fully interactive.
--- clip --- Leaving the issues of implementation behind for the moment, in a perfect world we want the interactivity of PyGeo/OpenGl with the quality of PovRay. Since that is impossible (at least with our resources) the next best thing is to be able to debug with lower (graphical) quality higher speed interactive tools and then do hardcopy with PovRay. In this better but less than perfect world we would have a higher level abstraction that could map into eithor output method at the users discretion. The concept of a common abstraction with drivers hiding the details of the implementation is not rocket science. On the other hand adding a level of abstraction also adds to the complexity (cost) of a project. Today we have two people generating useful work. If we wait for the development of a spec and the implementation of an abstraction layer everything would stop for a while. Another disadvantage of such an approach is that it is a lowest common denominator kind of thing. Adding features gets harder because they have to be implemented and debugged in both backends.
Leaving the issues of implementation behind for the moment, in a perfect world we want the interactivity of PyGeo/OpenGl with the quality of PovRay.
In support of our effort to integrate Python with the physics curriculum here, I am working on a Python visualization library which aims to provide both high rendering quality and "automatic" interactivity to Python programs. The interface aims at allowing the user to write "zero graphics code" by making the graphics primitives useful data structures. For example, from visual import * ball = sphere() ball.momentum = vector(10,0,0) ball.mass = 3.0 dt = 0.1 while 1: ball.position = ball.position + ball.momentum/ball.mass*dt 'momentum' and 'mass' are attribute names invented by the user - any names could be used. Python's __getattr__ and __setattr__ mechanism allows me to make changing the ball's built-in 'position' attribute actually move the ball on the screen in real-time. At present, I am working with a prototype implementation which, like PyGeo, uses PyOpenGL for rendering. Once we are satisfied with the interface, I plan to re-implement the library with a custom graphics engine in C++, which will probably use OpenGL directly to render polygons (if it's good enough for Quake 3... :). Although it obviously won't be a raytracer, the presence of an engine written by knowledgable graphics coders in a fast implementation language makes all kinds of powerful rendering techniques available. For example, the engine could transparently do stereo rendering with anaglyph or shutter glasses, replace lines with shaded cylinders or alpha 'trails', interpolate curves for added detail, or reduce unnecessary detail in order to maintain a high frame rate. It could also support advanced primitives like height and even volume fields at interactive frame rates. The internals of the graphics engine aren't intended to be exposed to the beginning coder, any more than the internals of the Python interpreter or the OpenGL library itself are. I don't see that as a problem - you have to draw the line at *some* level of abstraction.
Since that is impossible (at least with our resources) the next best thing is to be able to debug with lower (graphical) quality higher speed interactive tools and then do hardcopy with PovRay.
For our purposes, animation and even interactivity are very important, so we haven't seriously considered a non-real-time back end implementation, but the level of abstraction of the interface is already adequate to make this possible.
Another disadvantage of such an approach is that it is a lowest common denominator kind of thing. Adding features gets harder because they have to be implemented and debugged in both backends.
Indeed. In fact, even releasing a prototype makes it harder to make changes because you instantly have a group of users who are used to the "old way." I think it's a good idea to "let a thousand flowers bloom" at the moment. There are all kinds of ways that separate efforts could be integrated later - for example, PyGeo is an interactive 'application' that could easily run on top of my library instead of PyOpenGL and enjoy both simpler code and better rendering quality. A "dump screenshot to povray" feature could then be added to my library, and you would have the best of all worlds. Dave
Steve Morris wrote:
Leaving the issues of implementation behind for the moment, in a perfect world we want the interactivity of PyGeo/OpenGl with the quality of PovRay.
Since that is impossible (at least with our resources) the next best thing is to be able to debug with lower (graphical) quality higher speed interactive tools and then do hardcopy with PovRay.
fwiw, you just described caligari's trueSpace 4 (fast interactive rendering via DirectX or OpenGL, high-quality raytracing for output, and a built-in Python interpreter... but not exactly free, of course...) </F>
(fast interactive rendering via DirectX or OpenGL, high-quality raytracing for output, and a built-in Python interpreter... but not exactly free, of course...)
</F>
<SOAP BOX> Re news of some of the latest projects -- We already know that Python is a powerful and capable language. So is C++, so is Java -- a host of others (e.g. the LISP varieties -- some claim Scheme is no longer a LISP (an irrelevant aside, I know)). So I have no doubt that many talented and accomplished programmers are going to use Python and JPython to create whiz bang gee whiz applications that help students learn a variety of subjects. But this is nothing new. We already have an embarrassment of useful software, a lot of which is having a hard time finding its way into the standard curriculum -- simulations, dynamic geometry programs and so on, all with their advantages and disadvantages. The question in my mind is how to open up the world of programming to more people. I'm especially interested in doing this in a non-CS context (my students haven't necessarily committed to following any CS curriculum). To this end, even the best application/simulation/killer app ever conceived, for teaching geometry or physics or whatever, might be completely irrelevant from the standpoint of opening up the world of programming to a wider audience -- because the code is hard, difficult to comprehend (doesn't mean inelegant, just means "done by a pro" (or by a hacker -- sometimes it's a very fine line...)). In sum, when it comes to "proving Python can drive sophisticated apps with GUIs, real time graphical feedback", I have no doubts. I know that's true. But my initial reaction is "so what?". What does this have to do with CP4E? Just being a devil's advocate (a role I'm probably all too accustomed to playing). My mentioning of Struck in this context (earlier post) was in line with the goal of giving students deeper insights into coded namespaces. Gerald de Jong, founder of beautifulcode.nl, specifically wrote Struck in a way he hoped demonstrated elegant _simple_ Java code (he trains people in Java for a living, has flown to Tokyo and places to show how it's done -- not unlike Bruce Eckel in this regard). The amazing thing about Struck isn't how much goes on "under the hood", but how LITTLE. And yet you get a lot of screen activity, the ability to do animations -- from a very _tiny_ reiterative vector processor. I, for one, am not in on this listserv because I'm trolling for potential collaborators on some "killer app". That might happen, inadventently, but my focus is finding ways to open up the world of programming to more students. To this end, I think Python is already adequate as is (as I've been saying from the beginning), and no additional apps are essential to furthering these goals. I'm sure the next IDLE will be even better, and eagerly await its debut, but 0.5 is certainly usable as is. No need to sit around twiddling my thumbs waiting for Guido to provide: he's already made a tremendous contribution, is not himself a bottle neck of any kind. Seems to me that most of the relevant barriers to CP4E are political and administrative. The technology is not the problem. The problem is a creaky, obsolete, boring, unimaginative curricula. What I'm doing is setting some new standards (yes, using Python as a part of the mix), so that I can go out to world and say "look, any of you other curriculum writers _could_ be doing stuff more like this -- don't you think this makes a lot of sense, compared to what's run-of-the mill today?". </SOAP BOX> Kirby
(fast interactive rendering via DirectX or OpenGL, high-quality raytracing for output, and a built-in Python interpreter... but not exactly free, of course...)
</F>
<SOAP BOX>
since I don't understand why my pointer to Caligari's 3D application resulted in this kind of response, I hereby pro- mise to remain silent in the future. apologizing for the inconvenience, etc /F
I wish there was less taking of offense on this list. Different people want to get different things. Kirby in particular is an "on the ground" type of contributor adding what he things is important. (I love his numericy pages, check them out.) This means he has well focused ideas he would like to see come out of this list and CP4E. He is apparently afraid that the grandious ideas will dilute the effort resulting in little accomplishment. On the other hand he is just one of many. For example I think he sets the goals too low and we have room to explore many approaches. However I fail to see why he shouldn't be allowed to present his opinion and try to convince the rest of us without everyone taking offense apparently merely because he disagrees with them. He and I have had occasion to disagree on several things so far. I don't have less respect for him because of it and I don't believe he has less respect for me or anyone else that disagrees with him. So what's the problem? This is a subject that is bound to have plenty of disagreement among intelligent people of good will. Lets please assume that each of us is one of these intelligent people of good will having these inevitable disagreements and chill out a little. Just a suggestion ;-)
participants (4)
-
David Scherer -
Fredrik Lundh -
Kirby Urner -
Steve Morris