Procedures Opportunities Database Awards Undergraduate Research Day & CS Participants 497 Abstracts Contact Info Research in Other Departments Interdisciplinary Research Centers Chemistry UGR Opportunities Earth and Atmospheric UGR Opportunities Physics UGR Opportunities Seminars CS Events Calendar Math Events ECE Events

Vpython Project More info on the Vpython development http://secant.cs.purdue.edu/ Description of possible projects: 1) Study, experiment with, and modify the thread priority management on Windows. This code is entirely different from the Linux code. On Linux we use GTK2; on Windows we use native Windows mechanisms, because currently it seems to be extremely difficult for an end user to install GTK2 on Windows (though it would clearly be highly desirable to be able to use platform-independent code for creating windows for OpenGL and handling mouse and keyboard events). Presumably a student would need to be quite strong to tackle this issue. What I can provide includes a suite of programs that fail. Working in this area, the student would presumably also encounter and document crashes. I don't feel that I currently see a clear pattern in crashes that would permit specifying at this time a project to address them."Fix the crashes" is hopelessly vague, as is "Find out why programs crash on some XP machines and not on others." What I'm hoping is that addressing the thread priority issues may also address some crashes and lockups (thread lock contention). At the very least, getting thread management under control ought to let any remaining problems stand out more clearly. 2) Create a native-mode version for the Mac. It happens that there never has been a Mac expert involved with VPython development. For that reason, the Mac version simply piggy-backs off the Linux version. The end user has to install X11 and fink (the open-source package manager for Mac Unix) before attempting to install Python and the Visual module. There are many ways for this complex chain of installs to fail, many of them having nothing per se to do with Visual. It would be wonderful to have a version of VPython that used native Mac graphics (create a window for OpenGL and handle events) and didn't require installing X11 (and fink) at all. The amount of code is I believe quite small. 3) There are various small gaps that a student could usefully fill in. Stereo modes "active" and "crosseyed" have not been implemented."scene.cursor" is not implemented and gives an error (used in old programs to make cursor visible/invisible). The University of Toronto student who worked on Visual last spring added code to implement sophisticated lighting of box objects (by splitting a box face into many small faces); it would be good to add similar code for cylinders, arrows, and perhaps faces. At a similar level of relatively small but useful projects would be to implement hollow cylinders. 4) There are some small glitches that should be fixed (the list is taken from the bug section of the summary of new features found in the "Recent developments" section of vpython.org): Autoscaling is pretty good but occasionally positions the camera farther from the scene than you would prefer. I implemented this machinery myself, last summer, so I can give some advice and counsel. A significant innovation compared to the production version is that I built in some hysteresis to avoid the fibrillation sometimes seen in the production version, where the camera moves forward and back and forward and back as the scene changes size, which can be confusing to students. In a column of many rings along the x axis, at least on Windows, occasionally a ring is briefly rendered wrong. Rendering of curves isn't quite right. This can be seen in the example program tictac.py, where one of the grid lines doesn't show until you rotate the view. Spotlights created in a frame don't change with changes in the frame orientation but should.