Menu
▾
▴
visualpython-users
|
From: Fortemps P. <Phi...@fp...> - 2001-03-21 15:31:11
|
Hello, I really appreciate to use VPython to graph the output of my programs. How could I send those graphs to a PostScript file ? If VPython is built on Tk, how can I reach canvas.postscript ? Many thanks, Philippe ********************************************************** FORTEMPS Philippe Mons Institute of Technology (F.P.Ms) Mathematic & O.R. tel:+32-65-374685 Rue de Houdain, 9 fax:+32-65-374689 B-7000 Mons BELGIUM email:Phi...@fp... ********************************************************** |
|
From: Markus G. <gr...@iu...> - 2001-03-21 15:49:32
|
Fortemps Philippe wrote: > I really appreciate to use VPython to graph the output of my > programs. How could I send those graphs to a PostScript file ? Maybe you want to export the scene to a PovRay file and render it at a high resolution to get perfect pictures. > If VPython is built on Tk, how can I reach canvas.postscript ? I don't think that visual is build on Tk, is it? Markus |
|
From: David A. <dm...@an...> - 2001-03-21 16:03:35
|
Exporting to PovRay is the way to go. Visual is not built on Tk, tho you can use Tk with visual (in another window). |
|
From: Ari H. <ahe...@an...> - 2001-03-21 16:34:00
|
On Wed, Mar 21, 2001 at 11:03:37AM -0500, David Andersen wrote: > Exporting to PovRay is the way to go. > I would just capture a screenshot and convert that to PostScript. PovRay renderings will of course look nicer if you have the patience for them. ari |
|
From: Markus G. <gr...@iu...> - 2001-03-21 16:48:35
|
Ari Heitner wrote: > PovRay renderings will of course look nicer if you have the patience for > them. Well, PovRay rendering takes only a few seconds on my slow P200. Rendering VPython scenes is quite fast, because most timeconsuming features in rendering (transparency, reflection, area lights for soft shadows, radiosity, ...) are not used. Markus |
|
From: Ari H. <ahe...@an...> - 2001-03-21 16:57:31
|
On Wed, Mar 21, 2001 at 05:48:22PM +0100, Markus Gritsch wrote: > Ari Heitner wrote: > > > PovRay renderings will of course look nicer if you have the patience for > > them. > > Well, PovRay rendering takes only a few seconds on my slow P200. Rendering > VPython scenes is quite fast, because most timeconsuming features in > rendering (transparency, reflection, area lights for soft shadows, > radiosity, ...) are not used. > Hm, I guess that's a good point. Actually on the plate for the second half of this semester is a bunch of new stuff in VPython. Transparency will be tricky to do due to structural issues in VPython (transparency in GL requires careful observance of zbuffer and render-order rules) but textures should be starting to happen in the next couple of weeks. Ari |
|
From: Markus G. <gr...@iu...> - 2001-03-21 17:01:04
|
Ari Heitner wrote: > Actually on the plate for the second half of this semester is a bunch of new > stuff in VPython. Transparency will be tricky to do due to structural issues > in VPython (transparency in GL requires careful observance of zbuffer and > render-order rules) but textures should be starting to happen in the next > couple of weeks. Looking forward to it! Markus |
|
From: ruth c. <rc...@an...> - 2001-03-21 17:06:00
|
--On Wednesday, March 21, 2001 11:34 AM -0500 Ari Heitner <ahe...@an...> wrote: > On Wed, Mar 21, 2001 at 11:03:37AM -0500, David Andersen wrote: >> Exporting to PovRay is the way to go. >> > I would just capture a screenshot and convert that to PostScript. > > PovRay renderings will of course look nicer if you have the patience for > them. > Huh? I export stuff to PovRay all the time to make figures for a physics textbook. Rendering is fast -- no patience required. Ruth > > > ari > > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > http://lists.sourceforge.net/lists/listinfo/visualpython-users |
|
From: Ari H. <ahe...@an...> - 2001-03-21 17:23:59
|
On Wed, Mar 21, 2001 at 12:05:42PM -0500, ruth chabay wrote: > > > PovRay renderings will of course look nicer if you have the patience for > > them. > > > Huh? I export stuff to PovRay all the time to make figures for a physics > textbook. Rendering is fast -- no patience required. > I think computers got faster when I wasn't looking. ... Clearly we need to add more transparency/soft shadows/reflection support to the povray export module to slow down all this dangerous, irrationally exuberant fast rendering. ari |
|
From: Markus G. <gr...@iu...> - 2001-03-21 17:30:56
|
Ari Heitner wrote: > Clearly we need to add more transparency/soft shadows/reflection support to > the povray export module to slow down all this dangerous, irrationally > exuberant fast rendering. :-) First, implement it in VPython - povexport will continue reproducing VPython features. (Although textures are already there, even before this feature pops up in VPython ;-) Markus |
|
From: Bruce S. <ba...@an...> - 2001-03-21 17:09:05
|
Going through PovRay makes sense for normal 3D Visual scenes, but doesn't make a lot of sense for the 2D graphs Fortemps is interested in (produced by importing visual.graph). And capturing a screen shot gives you low resolution when you go to print. So really what is needed (I think) is for someone to write a module to go from a Visual scene (or graph) to Postscript, analogous to what Ruth Chabay has done for going to PovRay. This might be useful even for 3D scenes if you don't care about the ray-traced quality obtained from PovRay. VPython is most definitely not built on Tk. The only connection is that Tk underlies IDLE, but not Visual. Bruce --On Wednesday, March 21, 2001 4:31 PM +0100 Fortemps Philippe <Phi...@fp...> wrote: > I really appreciate to use VPython to graph the output of my > programs. How could I send those graphs to a PostScript file ? > > If VPython is built on Tk, how can I reach canvas.postscript ? |
|
From: Markus G. <gr...@iu...> - 2001-03-21 17:17:48
|
Bruce Sherwood wrote: > So really what is needed (I think) is for someone to write a module to go > from a Visual scene (or graph) to Postscript, analogous to what Ruth Chabay > has done for going to PovRay. This might be useful even for 3D scenes if > you don't care about the ray-traced quality obtained from PovRay. For a moment i thought about this, too, but this would be a *LOT* of work if you would like to reproduce the scene exactly, although it would not be impossible. Maybe things would simplify if only 2D is considered, but creating a reasonable PostScript image of a 3D scene is quite complicated (geometry transformation, color shading, ...). Markus |
|
From: David S. <dsc...@vy...> - 2001-03-22 01:06:41
|
For printing graphs, the best thing would probably be to bring in another graphing or drawing package that supports high-quality postscript output, and write code to convert a visual.graph into that package's conception of a graph. "Direct" high-resolution printing of 3D scenes could be done by modifying cvisual to point its OpenGL context at a high-resolution WMF in memory and rendering a frame. That approach obviously requires some C++, OpenGL, and Windows programming skills. The POV approach also doesn't sound bad, although I haven't tried it. Maybe for convenience povexport.py should be able to run POVray through os.system()? Dave > -----Original Message----- > From: vis...@li... > [mailto:vis...@li...]On Behalf Of > Markus Gritsch > Sent: Wednesday, March 21, 2001 12:18 PM > To: Bruce Sherwood; vis...@li... > Subject: Re: [Visualpython-users] How to print ? > > > Bruce Sherwood wrote: > > > So really what is needed (I think) is for someone to write a > module to go > > from a Visual scene (or graph) to Postscript, analogous to what > Ruth Chabay > > has done for going to PovRay. This might be useful even for 3D scenes if > > you don't care about the ray-traced quality obtained from PovRay. > > For a moment i thought about this, too, but this would be a *LOT* > of work if > you would like to reproduce the scene exactly, although it would not be > impossible. Maybe things would simplify if only 2D is considered, but > creating a reasonable PostScript image of a 3D scene is quite complicated > (geometry transformation, color shading, ...). > > Markus > > > > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > http://lists.sourceforge.net/lists/listinfo/visualpython-users > |
|
From: Ari H. <ahe...@an...> - 2001-03-22 08:05:22
|
On Wed, 21 Mar 2001, David Scherer wrote: > For printing graphs, the best thing would probably be to bring in another > graphing or drawing package that supports high-quality postscript output, > and write code to convert a visual.graph into that package's conception of a > graph. > heheheeh. i vote for a conversion tool that uses the SML-NJ "Turtle" postscript-output language .... a python module that generates Turtle code (which runs under SML). ari |
|
From: Ihor R. <ro...@tu...> - 2001-03-23 08:13:28
|
Bruce Sherwood wrote: > For printing graphs, the best thing would probably be to bring in another > graphing or drawing package that supports high-quality postscript output, > and write code to convert a visual.graph into that package's conception of a > graph. Simply use Dislin http://www.linmpi.mpg.de/dislin Visual should not be 'the best tool for everything'. I.Rokach |
|
From: Bruce S. <ba...@an...> - 2001-03-24 03:07:40
|
--On Friday, March 23, 2001 09:13 +0100 Ihor Rokach <ro...@tu...> wrote: > Bruce Sherwood wrote: >> For printing graphs, the best thing would probably be to bring in another >> graphing or drawing package that supports high-quality postscript output, >> and write code to convert a visual.graph into that package's conception >> of > a >> graph. > > Simply use Dislin > > http://www.linmpi.mpg.de/dislin > > Visual should not be 'the best tool for everything'. It was Dave Scherer who said this, not me. I went and looked at Dislin, and it wasn't obvious to me how this would address the problem. For starters, it isn't available for the Macintosh, and only certain versions are freeware. Is Dislin intended to display on the screen or to a printer (or both)? I agree with the notion that Visual doesn't have to do everything, but being able to print (at high resolution) the graphs that are already being produced in VPython certainly seems a desirable feature. Ihor, can you explain what role (if any?) Dislin could play in making it possible to print a graph produced by visual.graph? Bruce Sherwood |
|
From: Ihor R. <ro...@tu...> - 2001-03-25 09:19:40
|
Bruce Sherwood wrote:
>It was Dave Scherer who said this, not me.
Oh, excuse me!
> I went and looked at Dislin, and it wasn't obvious to me how this would
> address the problem. For starters, it isn't available for the Macintosh,
> and only certain versions are freeware. Is Dislin intended to display on
> the screen or to a printer (or both)?
First of all, according to the documentation,
" DISLIN is a library of routines for easy drawing of axis sys-
tems, curves, legends, bar graphs, pie charts, 3-D colour
plots, surfaces, contours and maps The software is available
for several C, Fortran 77 and Fortran 90 compilers."
DISLIN is free for all free operational systems and for all free
compilers for non-free OS. All DISLIN extensions for Python (as well as for
Perl or Java) are free. Thus, most of DISLIN versions are freeware.
Last year there was a long-time discussion in the NumPy mailing list
about the quality and capabilities of different plotting libraries available
for Python. The conclusion was that DISLIN is very flexible and rich library
and gives the highest quality of a hardcopy.
> I agree with the notion that Visual doesn't have to do everything, but
> being able to print (at high resolution) the graphs that are already being
> produced in VPython certainly seems a desirable feature.
My point was to use DISLIN _instead_ of Visual to produce graphs.
Visual is the best tool to produce 3D animations, etc. In my opinion,
however, there are many other more suitable tools to produce 2D plots.
Please, do not start to reinvent a wheel ! The last C-version of DISLIN
consist of 565 functions. Are you going to make your 'plot making part' of
Visual larger and more powerfull? Perhaps, it would be better to improve
more 'native' Visual capabilities.
> Ihor, can you explain what role (if any?) Dislin could play in making it
> possible to print a graph produced by visual.graph?
You can use DISLIN for plotting graphs on screen as well as to save it
in several different formats (WMF, PNG, PPM, Postscript and PDF included).
On Windows you can print plots directly if your printer is HP-compatible.
BTW, OOP addicts may use a bit outdated pxDISLIN (an object-oriented
wrapper around the DISLIN) available at
http://pantheon.yale.edu/~pmm34/pxdislin.html
With best wishes,
Ihor Rokach
|
|
From: Bruce S. <ba...@an...> - 2001-03-25 19:50:09
|
It sounds like DISLIN is ideal for sophisticated creation of graphs, and those who need this power should use it. It sounds like there is no particular reason for VPython to have any particular connection to DISLIN, or am I still missing something? (And I repeat, it does not seem to be available for Macintosh at all.) --On Sunday, March 25, 2001 10:19 +0200 Ihor Rokach <ro...@tu...> wrote: > My point was to use DISLIN _instead_ of Visual to produce graphs. > Visual is the best tool to produce 3D animations, etc. In my opinion, > however, there are many other more suitable tools to produce 2D plots. > Please, do not start to reinvent a wheel ! The last C-version of DISLIN > consist of 565 functions. Are you going to make your 'plot making part' > of Visual larger and more powerfull? Perhaps, it would be better to > improve more 'native' Visual capabilities. I think there are two different kinds of use. Sophisticated users need a sophisticated graphing package, and DISLIN may be it. My intro physics students need some very simple autoscaled graph capability of the kind offered by visual.graph. If I had known about DISLIN perhaps I could have gotten the simple capability I need by wrapping some DISLIN functions, though the unavailibility for Macintosh would have prevented going in this direction. I have no desire to add features to visual.graph: it is what it is -- a very basic graphing routine. And I do not have the time nor currently the expertise to improve Visual itself, so my working on visual.graph did not take anything away from the evolution of Visual. Perhaps you (or someone else) could contribute a replacement for visual.graph, based on DISLIN or whatever, and if it had the properties my students need I would definitely use it. Or if this is not feasible (or not available for Macintosh), then it would be nice to have a module that could produce Postscript starting from visual.graph. Someone familiar with Postscript could presumably create such a module quite quickly, whereas at the moment I'm trying to finish a physics textbook for publication this summer. Bruce Sherwood |
|
From: Ihor R. <ro...@tu...> - 2001-03-26 14:45:02
|
> From: Bruce Sherwood <ba...@an...>
> (And I repeat, it does not seem to be available for Macintosh at all.)
Yes, It is not available for Mac due to very simple reason - Helmut
Michels (DISLIN creator) has no Mac in his institute.
> I think there are two different kinds of use. Sophisticated users need a
> sophisticated graphing package, and DISLIN may be it. My intro physics
> students need some very simple autoscaled graph capability of the kind
> offered by visual.graph.
DISLIN contains so called 'quickplots' which are ideal for your purposes.
The following simple example plots a function on the screen
from Numeric import *
from dislin import *
x=arange(100)
qplot(x,sin(x/5.0),100)
To save a plot in Postscript you should add line
metafl("post")
before calling qplot. There are similar one-line functions for plotting 3D
colour plot, surface plot, contour plot, etc. I think it exactly the thing
your students need. You can find more information about using DISLIN with
NumPy in the SHORT article at
http://www.oreillynet.com/pub/a/network/2000/06/02/magazine/numerically.html
printer-friendly version -
http://www.oreillynet.com/lpt/a/231
Ihor Rokach
|
|
From: Bruce S. <ba...@an...> - 2001-03-28 18:49:44
|
I installed DISLIN, tried a simple demo, and looked at the documentation. DISLIN is an excellent graphing package to go with Python, but as far as I can tell it does not address the graphing needs of my physics students. (And I don't see how to get a Mac version created.) The input to DISLIN plotting routines are arrays of data. We don't even teach our students about arrays! A typical student program computes step by step the motion of (say) a binary star, with a display of the two stars in motion. Often there is an accompanying graph of (say) energy vs. time, with data points added one at a time to the graph as they are computed. Both the motion of the stars and the graph evolve in time, with continual updates. The reason why we are able to introduce serious computer modeling with 3D animations into an introductory physics course is that we can spend just 50 minutes teaching a very small subset of Python, adequate for modeling a range of physical systems, even if the student has never written a program before. In this minimalist situation, arrays are one of the very many features of Python which we don't introduce. Moreover, we want the graph and the animation to run continuously, in parallel. If the issue were simply that of making graphs, in the absence of DISLIN we could just have students write data to a data file and import that file into Excel or other graphing package. Being able to graph incrementally is a bit tricky, because for autoscaling you need incrementally to detect the need to change the axes, tick marks, and labels, and rearrange the screen. That's what visual.graph does (and dislin doesn't, because it plots arrays, not individual points). So I say again that it would be useful to have the ability for visual.graph to output postscript and print, even with the availability of the excellent DISLIN library. Bruce Sherwood |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X