[Visualpython-users] VPython 5.60

New in Visual 5.60 for Windows, Mac, and Linux:

* Facilities to extract faces data from extrusion and text objects;
see the documentation for these two objects. I had hoped that
converting an extrusion or text object to a faces object would result
in faster rendering, but in fact it usually doesn't, and in some cases
it renders significantly more slowly. I suspect this has to do with
the unavoidable manipulation of large arrays in the faces object,
though I'm surprised, because I would have thought that reading up the
vertices and normals for a triangle would be faster than figuring out
what vertices and normals to draw (as the extrusion code must do).

However, we are using the new conversion facilities to upgrade the
povexport module to permit exporting extrusion and text objects to
Pov-ray for high-quality (non-real-time) creation of high-resolution
versions of VPython scenes. This work is not quite done.

* The ability to make extrusion and text objects single-sided for
increased speed. By default, all VPython objects other than the faces
object are two-sided. For example, if you move inside a box, you see
the inner sides of the box. In many cases you might not care about
this two-sidedness, and an extrusion or text object will render a
little bit faster if you say twosided=False.

* Kadir Haldenbilen has improved the gear facilities in the shapes
library, and added rack gears (linear gears, that mesh with circular
gears). He has also contributed another example program,
extrusion_examples.py, that you will find quite useful as an overview
of what one can do with extrusion objects.

* The feature scene.show_rendertime = True has been revised because it
was discovered that it was not displaying accurate information. Now if
you set scene.show_rendertime = True, in the lower left corner of the
display you will see something like "cycle: 40" (without the estimate
of the time required to render the scene), meaning 40 milliseconds
between renderings of the scene. The minimum cycle time is about 30
milliseconds (about 30 renderings per second). Approximately half of
the cycle time is devoted to rendering the scene, and about half to
your own computations; longer cycle times reflect longer render times
(but with 50% of the time still dedicated to computations). If the
scene is not very complicated, very little time is needed to render
the scene, and almost all the time is given to your computations.

Along with this correction to the reporting, a mistake was corrected
that could lead to very short cycle times, which is pointless, because
producing 150 images per second serves no human purpose.

Bruce Sherwood